v':''r'r' 


'iCj:.VV',V«',."'''j-i.'','I  /" 


.iy 


NAVAL  POSTGRADUATE  SCHOOL 

Monterey,  California 


THESIS 

THE  SOFTWARE  ENGINEERING  PROTOTYPE 

by 

Michael  R.  Kirchner 

June  1983 

Th€ 

isis  Advisor:            Gordon  C. 

Howe 

11 

Approved  for  public  release;  distribution  unlimited 


T210117 


t*A  ^ 


SECURITY  CUASSIPICATION  OP  THIS  PAGE  (Wht\  Dmtm  Enturmd) 


Monterey,  CA  93943 


REPORT  DOCUMENTATION  PAGE 


READ  INSTRUCTIONS 
BEFORE  COMPLETING  FORM 


I.    REPOHT  NUMBER 


2.  GOVT  ACCESSION  NO. 


3.     RECIPIENT'S  CATALOG  NUMBER 


4.    TITLE  (and  Subtltlt) 

The  Software  Engineering  Prototype 


5.     TYPE  OF  REPORT  &   PE-RIOD  COVERED 

Master's  Thesis 


6.     PERFORMING  ORG.   REPORT  NUMBER 


7.    AUTHORr«> 

Michael    R.    Kirchner 


a.     CONTRACT  OR  GRANT  NUMBERr*; 


•  •    PeRFORMINOOROANIZATION  NAME  AND  ADDRESS 

Naval  Postgraduate  School 
Monterey,  California  93940 


10.     PROGRAM  ELEMENT.  PROJECT,  TASK 
AREA  &   WORK  UNIT  NUMBERS 


II.    CONTROLLING  Or^lCE  NAME  AND  ADDRESS 

Naval  Postgraduate  School 
Monterey,  California 


12.     REPORT   DATE 

June,    1983 


13.     NUMBER  OF  PAGES 


100 


U.    MONITORING  AGENCY  NAME  ft   AODRESSCi/ d<//*ran(  Irom  ConUoltlng  Oltlem) 


15.     SECURITY  CLASS,  (of  thia  roport) 


UNCLASSIFIED 


15«.     DECLASSIFICATION/  DOWNGRADING 
SCHEDULE 


te.    DISTRIBUTION  STATEMENT  (ol  Ihit  Report) 

Approved  for  public  release;  distribution  unlimited 


17.    DISTRIBUTION  STATEMENT  (of  lh»  mtattmct  anffd  /n  Block  30,  It  dlUartH  /ram  Rmport) 


le.    SURRLEMENTARY  NOTES 


19.    KEY  WORDS  fConlinu*  on  fvtf  aid*  It  n»e»aaarr  and  Idantlty  br  block  numbar) 


software  engineering,  software  prototype,  software  design, 
design  theories,  software  engineering  environments,  case 
studies,  software  development,  information  systems  development, 
system  development  life  cycle 


20.     ABSTRACT  (CoitUnua  on  ravarao  alda  It  naeaaaarr  and  Idantlty  by  block  numbar) 

Experience  has  shown  that  the  traditional  method  of  software  de- 
velopment often  has  poor  results.   Recently,  a  new  approach  to 
software  development,  the  prototype  approach,  has  been  proposed. 
This  thesis  presents  an  integrated  view  of  general  design  theorie^ 
and  relates  that  view  to  software  design  and  development.   The 
current  thought  on  prototypes  is  described  and  the  basic  require- 
ments for  a  software  engineering  environment  are  presented .  (Cont) 


DD 


FORM 
I  JAN  7S 


1473  EDITION  OF  1  NOV  6S  IS  OBSOLETE 

S/N  0)02-LF.  014- 6601 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (Whan  Data  Bntarmo^ 


SECURITY  CLASSIFICATION  OF  THIS  PACE  (Whan  Dmtm  Bnfnd) 


ABSTRACT  (Continued)   Block  #  20 

Software  prototypes  are  shown  to  support  the  integrated  view  of 
designs.   Four  case  studies  of  using  prototypes  are  presented 
and  recommendations  for  further  study  are  made. 


S'N  0102-  LF-  014-660) 


2       SECURITY  CLASSIFICATION  OF  THIS  PAGEfWh»ii  Dmtm  Enfrmd) 


Approved  for  public  release;  distribution  unlimited 

The  Software  Engineering  Prototype 

by 

Michael  R.  Kirchner 
B.S.,  Illinois  Benedictine  College,  1973 


Submitted  in  parxial  fulfillment  of  the 
requirements  for  the  degree  of 


MASTER  OF  SCIENCE  IN  INFORMATION  SYSTEMS 


from  the 


NAVAL    POSTGRADUATE    SCHOOL 
June    1983 


ABSTRACT 

Experisnce  has  shown  that  zhe  -craditional  method  of 
software  development  oftei:  has  poor  results.  Recently,  a 
new  approach  to  software  development,  -he  prototype 
approach,  has  been  proposed.  This  thesis  presents  an  inte- 
grated view  of  general  design  theories  and  relates  that  view 
to  software  design  and  development.  The  current  thought  on 
prototypes  is  described  and  the  basic  reguirements  for  a 
software  engineering  environment  are  presentad.  Software 
prototypes  are  showc  to  support  the  integrated  view  of 
design.  Four  case  studies  cf  using  prototypes  are  presented 
and  recommendations  for  further  study  are  made. 
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I-    INTHODaCTIOli 

Current  software  engineering  practices  are  bas«=d  on  a 
development  modal  which  is  10  to  15  years  old..  This  model 
is  often  referred  to  as  the  waterfall  model.  The  waterfall 
model  shows  the  development  of  software  as  a  series  of 
discrete   steps    [ Ref .    1r    2,    3,    4,    and    5]. 

Experience  indicates,  however,  that  software  development 
is  net  as  discrete  as  the  model  indicates,  so  the  model  has 
teen  rsfined  by  adding  loops  between  each  of  the  steps. 
Furthermore,  as  software  maintenance  has  gained  recognition, 
there  is  increased  pressure  to  refine  the  waterfall  model  to 
show  the  added  importance  of  maintenance  in  the  software 
life-cycle. 

The  software  engineering  profession's  concern  about 
software  maintenance,  which  is  more  properly  termed  refine- 
ment and  enhancement,  has  prompted  several  conjectures. 
Dodd  [Hef.  20]  has  suggested  that  the  current  cycl€  of 
develop,  inplement,  refine  and  enhance,  implement,  refine 
and  enhance,  implement,  and  so  on  is  really  the  construction 
and   refinement    of   a    prototype   system. 

Several  other  authors  have  suggested  that  we  should 
develop  software  prototypes  as  an  alternative  to  the  tradi- 
tional, or  waterfall,  approach  to  software  development 
[Ref.  68,  36,  62].  Their  principal  argument  is  that  the 
process  of  software  development  is  really  iterative,  slowly 
expanding  toward  a  ccmpleted  system.  Other  reasons  include 
enhanced  communications  between  the  user  and  designer,  fewer 
requirements  problems,  quicker  turnaround  between  initial 
system  need  and  initial  system  implementation,  to  name  a 
few. 
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The  process  of  devslcping  a  software  prototype  has 
significart  inruitive  appeal  for  asers  and  managsrs;  they 
can  try  a  system  cut  before  comcQitting  "chemselves"  to  a 
system  which  is  either  unsatisfactory  or  undelivered.  Aside 
from  this  appeal  and  the  benefits  often  cited,  there  seems 
to  be  little  discussion  about  the  principles  underlying  the 
development   of   software   prototypes. 

This  thesis  presents  one  view  of  how  the  process  of 
developing  software  prototypes  supports  some  basic  elements 
of  general  design  theory  and  software  design  specifically. 
Chapter  II  develops  an  integrated  set  of  design  elements 
based  en  several  published  models  of  the  general  design 
process.  Chapter  III  relates  these  design  elements  tc  soft- 
ware development  by  citing  examples  from  the  computing  and 
information  science  literature.  The  purpose  is  to  show  that 
software    design    is    similar    to   other    fields    of   design.' 

Chapter     IV      introduces    the      software      prototype.  The 

process  of  developing  software  prototypes,  their  roles  as 
iDodels,  construction  strategies,  and  the  principal  uses  of 
prototypes  are  described.  The  chapter  concludes  by  shewing 
how  prototypes  support  the  design  elements  from  Chapters  II 
and  III.  Chapter  V  briefly  describes  the  essential  features 
of  software  engineering  environments,  especially  those 
features  which  are  needed  for  developing  software  proto- 
types. Chapter  VI  presents  four  case  examples  which  illus- 
trate the  process  of  developing  a  software  prototype.  These 
cases  were  chosen  because  in  each  of  them  there  was  an 
explicit  decision  to  use  prototypes.  Chapters  VII  and  VIII 
present   Conclusions    and   Recommendations    for  Further    Study. 


'To      paraphrase    Gertrude      Stein:         Design      is    design      is 
design   is   design. 
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II.     MODELS    OF    DESIGN    METHODS 

A.       SIBOCTOBED    MODELS   OF    DESIGH 

Th€  ideas  about  design  and  design  methods  have  undergone 
some  significant  changes  in  the  last  20  years.  The  early 
models  placed  their  emphasis  on  the  process  of  design. 
These  models  had  a  rational,  discrete  notion  of  design  in 
which  the  design  process  was  thought  to  be  a  sequence  of 
wall-defined,  highly  structured  activities,  Many  theorists 
applied  the  ideas  and  principles  of  the  scientific  methcd  to 
the  process.  Alexander  [Rsf.  6]  was  one  of  the  earliest  of 
the  design  theorists  to  carefully  explain  design.  His  three 
most    significant  contributions   were: 

1.  The  symmetry  cf  the  design  problem — that  is,  design 
has  two  symmetical  parts,  the  form  (the  solution  to 
the  problem)  and  the  context  (the  setting  which 
defines  the  prcblem)  .  "...  adapta-icn  is  a  mutual 
phencmenon  referring  to  the  context's  adaptation  to 
the  form  as  much  as  the  form's  adaptation  to  it's 
context  ..."  The  design  problem  is  an  effort  to 
achieve  "fitness"  between  the  form  and  it's  context. 
[Hef .   6] 

2.  The  formal  decomposition  of  a  se-c  of  requirements 
into    successively  smaller   subuni-cs. 

3.  The  importance  of  diagrams  in  design.  A  diagram,  for 
Alexander,  is  "[a]ny  pat-ern  which,  by  being 
abstracted  from  a  real  situation,  conveys  the  phys- 
ical influence  of  certain  demands  or  forces  ..." 
[Bef-   6:    p.    85] 
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Alexander  chose  tc  emphasize  the  process  of  deccnpos'^-ior. 
in      his   early      work.  This   process      was      divided    into      two 

phases,    analysis  and    synthesis. 

In  analysis,  the  designer,  faced  with  a  problen,  derives 
a  mental  picture — often  vague  and  unsatisf actory--of  the 
demands  of  the  context,  and  then  decomposes  that  picture 
into  sets  (a  mathematical  picture)  .  Synthesis  begins  by 
developing  diagrams  (tased  on  the  sets) ,  using  the  diagrams 
to  form  a  design,  and  then  deriving  the  form  (see  Figure 
2.1).  Alexander   also     discussed  evaluation      (he   calls     it 

"goodness  of  fit").  Goodness  of  fit  is  determined  by  one  of 
two  criteria,  experimental  or  non-experimental.  The  experi- 
mental criterion  is  trial  and  error  where  "[  t  ]he  experiment 
of  putting  a  prototype  form  in  the  context  itself  is  the 
real    criterion      of      fit."        [Ref-    6:      p»        21].  The      ncn- 

experimental  criterion  is  "(a]  complete  unitary  description 
of  the  demands  made  ty  the  context  ..."  [Ref.  6:  p.  21]. 
Alexander  believes  that:  1)  trial  and  error  is  toe  expensive 
and  too  slow  and  2)  there  is  no  theory  which  can  express 
"...  a  unitary  description  of  the  varied  phenomena  of  a 
particular   context."     [Refo    6:    p.      20].  For  these   reasons 

he    concentrates    on   the   process    of   decomposition. 2 

Alexander's  structured  view  was  shared  by  many  theorists 
during   the      early    1960«s.         [Ref.    8,      7].  Archer    [Ref.    7] 

thought  of  design  as  a  goal-directed  activity.  The  goals  or 
objectives  cf  the  problem  define  the  properties  required  in 
the  sclution.  The  details  cf  the  design  are  the  designer's 
decisions  about  how  tc  implement  those  properties  [Ref.  7: 
p.    286]. 


2  Alexander        devotes        an        entire        Appendix        to        the 
"Mathematical  Treatment   of    Decomposition." 
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Figure   2.1        Alexander's  Design   Phases. 
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Archer  identifies  three  components  of  the  design 
process: 

1.  The   advance    through    the   project   and   through   tim-e; 

2.  The  branching  cf  xhe  problem  into  its  logical  parts; 
and, 

3.  A  problem-solving  process  cyclically  moving  through 
subproblems  (using  a  30-st9p  reiterative  operational 
model) . 

Jones  [Bef.  8]  called  the  thrae  stages  in  his  view  of 
the  design  process  divergence,  transformation,  and  conver- 
gence. He  was  quite  convinced  that  designers  should  think 
cf   these   stages    as   separate: 

...there  is  little  doubt  that  thair  separation  is  prere- 
quisite to  whatever  changes  of  methodology  are  necessary 
at  each  stage  before  they  can  be  reintearated  to  form  a 
process  that  works  well  at  the  systems  level.  [Ref.  8: 
P-    64] 


E.        aiCKID    FBOBLEMS 

These  early  models  ware  often  criticized.  One  critique 
suggested  that  design  problems  are  "wicked  problems"  and  are 
not,  therefore,  amenable  tc  structured  analysis  (and  deccm- 
pcsiticn) .      The    term    "wicked    problem"    refers   to    a 

.  .  .  .  class  of  social  system  problems  which  are  ill- 
formulated,  where  the  information  is  confusing,  where 
there  are  many  clients  and  decision-makers  with 
conflicting  values,  and  where  the  ramifications  in  the 
whcle    system    are    thoroughly   confusing.      [Ref.    9] 

Wicked   problems    have   the   following  properties    : 

1.      Wicked      problems  ae      ill-formulated.  They    have     no 

definitive  formulation  and  any  formulation  will 
correspond  tc  the  formulation  of  the  solution.  This 
means  that   any  time    a    formulation    is    made,    additional 
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questions  can  be  asked  and  more  information  can  be 
requested.  This  also     means      rhat   the      information 

needed  to  understand  the  problem  is  determined  by 
one's   idea   or      plan    cf   a   solution.  In   other   wcrds, 

whenever    a      wicked  problem      is    formulated      there   must 
already    be  a    solution   in   mind. 
2-      Wicked  problems  have      no   stopping   rule.        Any      time  a 
solution      is    fcrmulated,        it      could      be   improved     or 
worked  on   more.  One   can  stop   only      because   one   has 

run  cut  of  resources,  patience,  etc.  (An  architect 
cculd  keep  modifying  and  improving  a  design  solution 
fcrev€r--he  steps  because  ne  has  exhausted  his  fee, 
because  the  building  has  to  be  finally  built,  or 
because    he  has  exhausted   some    other   resource.) 

3.  Solutions  to  wicked  problems  cannot  be  correct  or 
false.  They  can  only  be  good  or  bad.  (There  is  no 
correct  or  false  building:  there  can  only  be  a  "gocd" 
building    or    a    "bad"    building.) 

4.  In  solving  wicked  problems  therr  is  no  exhaustive 
list  of  admissable  operations.  Any  conceivable  plan, 
strategy  or  act  is  permissable  in  finding  a  solution 
and   ncne    can    be   perscribed   as    mandatory. 

5.  For  every  wicked  problem  there  is  always  mere  than 
cne  possible  explanation.  The  selection  of  an  expla- 
nation depends  on  the  employed  world-view;  the  expla- 
nation also  determines  the  solution  to  the  problem. 
(The  high  cost  of  construction  of  a  building  may  be 
attributed  to  the  "expensive"  design,  to  the  high 
cost  of  materials,  to  the  wages  demanded  by  unions, 
to   high    interest   rates    and   inflation,    etc.) 

6.  Every  wicked  problem  is  a  symptom  of  another'  "higher 
level"  problem.  (If  the  maintenance  of  the  residence 
is  "too  expensive"  to  its  inhabitants,  this  indicates 
that  there  is  a  problem  with  the  income  of  its  inhab- 
itants. ) 
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7.  No  wicJced  problem  and  no  solution  to  it  has  a  defini- 
tive test.  In  ether  words,  any  time  any  tast  is 
"successfully"  passed  it  is  still  possible  that  the 
solution  will  fail  in  some  other  respect.  (If  large 
windows  are  designed  for  a  residence  to  provide  the 
desired  views,  the  heating  of  the  residence  may 
become  too  expensive.) 

8.  Each  wicked  picblem  is  a  "one  shot"  operation.  There 
is  nc  room  for  trial  and  error,  and  there  is  no 
possibility  fcr  experimentation.  (A  house  is 
designed  and  built- -there  is  no  going  back  to  the 
beginning   to    redesign   and   rebuild   it.) 

9.  Every  wicked  problem  is  unique.  No  two  problems  are 
exactly  alike  and  no  solutions  or  strategies  leading 
tc  solutions  can  readily  be  copied  for  the  next 
prcblem.  (Even  if  two  residences  are  designed  for 
the  same  family,  under  the  same  geographical  condi- 
tions they  will  never   be   identical.) 

10.  The  wicked  problem  solver  has  nc  right  tc  be 
wrcng — he   is    fully  responsible    for   his   action. 

If  design  problems  are  considered  as  wicked  problems, 
they  are  certainly  incompatible  with  the  early  lodels  of 
design.  The  early  models  clearly  separated  the  problem  from 
its  solution.  With  wicked  problems,  one  cannot  "define  the 
problem"--they      have      no    definitive      formulation.  If      one 

followed  the  procedures  of  the  early  models  of  iesign,  one 
should  be  able  to  establish  when  a  solution  was  clearly 
found.  Wicked  problems,  however,  have  no  stopping  rule. 
Some  cf  the  proponents  of  the  early  models  of  design  devised 
tests  for  design  solutions.  Alexander  argued  that  trial  and 
error  shculd  eventually  lead  to  "good  fit";  unfortunately, 
each   tiiE€    a   solution    is  tried,    the   problem   is  also    changed. 
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C.       ACCOHULATED    KNOWLEDGE    MODELS    OF    DESIGN 

''•      Design   is  Argumentative 

Oth-rT  design  models  were  proposed  following  the  criti- 
cisms of  the  early,  structured  models  of  design.  Rittel 
[Ref.  13]  views  the  whole  design  process  as  sequential 
problem      solving  in      which    the      cycles      form   networks.  An 

essential  parr  of  this  model  is  the  continuous  feedback 
between  tke  designer  and  the  problems  environment.  Rittel 
calls   this    •argumentation': 

.  .  .  .  the  designer  [is]  arguing  toward  a  solution  with 
himself  and  with  ether  parties  involved  in  the  project. 
He  builds  a  case  leading  to  a  better  understanding  of 
what  is  to  be  acccmDlisn ed.  In  izs  course,  sclu-rion 
principles  are  developed,  evaluated  in  view  of  their 
expected  performance  and  decided  upon.  The  parties 
commit  themselves  to  specific  courses  of  action  and  to 
the  risks  involved  in  them.  In  this  way,  better  formu- 
lations of  tha  problem  are  being  developed  simultane- 
ously with  a  clearer  and  clearer  image  of  the  solution. 
[Ref:    13    :   p.     19-20] 

If  arguments  are  improved  procedurally,  their  content  may 
improve        and  the        products        of  the        design — design 

decisions — may    also      be   expected   to    improve.  While    'argu- 

ing', the  parties  may  gain  new  insights  about  the  issue, 
expand  their  world-view,  modify  challenged  positions,  and 
learn   more    about   other  world-views. 

2»      Patterns    in    Cesign 

Alexander        introducsd      the        concept      of        pictoral 
diagrams      in     design     in         1964      [Ref.    6].  Significantly, 

Alexander   believed   that   the    design  diagrams   were    produced   b^ 
foSl^l,    rigorous   analysis,    a    design   process   founded    en    math- 
ematical   decomposition.        Since   then,         Alexander    and   others 
[Ref-    10]   have      concentrated  on      the    diagrams      (or   Patterns) 
rather   than   the    process. 
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Alexander's  patterns  are  not  a  resalt  of  rigorous 
analysis.  Rather,  design  is  a  process  of  acquirir.g  knowl- 
edge and  then  making  decisions  which  reflect  that  knowledge. 
The  crucial  issue  for  Alexander  is  the  availability  of 
knowledge.  That  is,  the  design  decision  depends  on  the 
accuiDulatsd  knowledge  of  the  designer.  Patterns  help  to 
provide  the  designer  with  the  necessary  knowledge  to  solve 
the  problem.  The  pattern  forms  the  basis  of  communication 
between  the  designer  and  the  client.  A  pattern  —  a  diagram 
of  what  the  designer  knows  and  believes  important  for  the 
problem — is  designed  and  then  passed  to  the  client.  The 
client  either  accepts  or  does  not  accept  the  pattern.  In 
either  case,  both  the  client  and  the  designer  gain  new 
knowledce:  if  the  pattern  is  not  accepted,  the  designer 
proceeds   to   change   the   design. 

^ •      Design    as  Learning 

Eazjanac  [  Ref .  15]  views  the  design  process  as 
formulating  the  problem  and  proceeding  with  a  search  for  the 
definition  cf  -he  solution.  He  emphasizes  that  the  forirula- 
tion  cf  the  problem  is  not  final.  The  formulation  reflects 
the  understanding  of  the  problem,  based  on  the  designer's 
knowledge,    at  that    time. 

Any  solution  ...  is  already  basically  determined  by  the 
definition  of  the  problem.  So  the  "search  for  solution" 
is  then  the  search  for  the  definition  of  the  specific 
solution  which  best  fits  the  knowledge  the  desianer  has 
at  that  time.  Once  the  specific  solution  is  defined  it 
is  documented.  Documentation  may  start  during  the  defi- 
nition cf  the  problem  and  continue  sporadically  during 
the  definition  of  the  solution--in  fact,  all  three 
phases      may  at      tiroes   take      place   simultaneously.  The 

ultimate  purpose  of  the  documentation  is  to  communicate 
the  definitions  of  the  problem  and  the  solution;  its 
immediate  purpose  is  to  aid  the  designer  in  the  defini- 
tion cf  the  problem  and  the  solution--to  help  him  detect 
new  aspects  of  the  problem  and  the  solution  and  to 
detect   inconsistencies   in    his   view.      [Ref.    15] 
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During  the  search  and  redefinition,  the  designer 
keeps  learning  more  atout  the  problem  and  the  solution.  The 
designer  gains  new  insights  which  ultimately  lead  to  a  new 
view--   redefinition.  The    process       (formulate   the    prctlem, 

search  for  the  definition  of  the  solution,  document  the 
specific  solution)  is  repetitive.  The  designer  continues  to 
re-define  and  document  new  formula-cions  until  1)  the  incre- 
mental gain  in  icnowledge  becomes  insignificant  and  cannot 
change  the  formulation  enough  to  warrent  redefinition,  2) 
the  incremental  gain  becomes  zoo  costly,  or  3)  the  designer 
exhausts   available   resources    (especially   time). 

**  •      nesiqn    is  Satisf  icing 

As  the  designer  and  user  learn  more  atout  the 
problem  and  as  the  sclution  becomes  clearer,  more  and  more 
design  decisions  are  negotiated  [Bef.  13,  15].  Since  these 
design  decisions  are  reached  through  compromise,  they  cannot 
be  called  optimal,  in  the  sense  of  management  science  and 
operations   research, 

Simon  [ Ref .  ^H]  has  introduced  the  idea  of  satis- 
ficii^g   tc    describe    these    kinds   of   negotiared    decisions. 


Normative   economics     has    shown      that   exact      solutions   to 


iplexity  the  real-world  business  firm  turns  tc  p: 
dures  that  find  gccd  enough  answers  tc  questions  whose 
best  answers  are  unknowable.  ...  man  is  ...  a  satis- 
ficer,  a  perscn  whc  accepts  "good  enough"  alternatives, 
not  because  he  prefers  less  to  more  bur  because  he  has 
no    choice.      [Ref.     1U:    p.    36] 
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D.  DESIGN  AS  A  TECHNOLOGICAL  ACTIVITY 

Cross  and  others  [  Ref .  16]  have  proposed  a  vi.ew  cf 
design  which  requires  the  explicit  acknowledgement  of  the 
organization's    role    in   design. 

•Technclogv*  ...  clearly  denotes  more  than  just  hard- 
ware, and  involves,  at  the  very  least,  consideration  of 
the  organizational  systems  within  which  machinery  is 
desiqnea,  commissioned,        operated        and      paid        for. 

•Technological*  achievements,  whether  those  of  building 
a  irajcr  bridge  or  cutting  a  man  on  the  moon,  are  as  much 
organizational  feats  as  technical  ones.  [Ref-  16:  p. 
198] 

These  ccnsideraticns  lead  to  their  view  that  a  "satis- 
factory" definition  cf  technology  has  the  following  charac- 
teristics: 

1.  Tschnoiogy   is   oriented   toward    practical  tasks. 

2.  Tschnoiogy  relies  on  different  kinds  of  organized 
knowledge,  of  which  scientific  knowledge  is  only  one. 
Craft  knowledge,  design  knowledge,  and  organizational 
and    managerial   skill    are   others. 

3.  Technological  activity  takes  place  in  an  crganiza- 
ticnal  context.      [Ref.    16:    p.    198] 

Cross  and  ethers  devcte  a  great  deal  of  space  to 
highlight  the  difference  between  knowing  "what  to  do" 
(scientific  knowledge)  and  knowing  "how  to  do"  (design  and 
craft  knowledge) .  Their  main  point  cannot  be  ignored:  the 
organizaticr  plays  as  large  a  role  in  design  as  does  the 
individual. 

E.  DESIGN    IS    EVCLOTICNART 

The  early  mcdels  of  design  were  frequently  criticized  for 
their  linear,  step-by-step  view  of  design.  Page  [Ref.  11] 
warned  that  the  design  process  is  not  executed  straight  from 
analysis   to   evaluation: 
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....in  the  majority  of  practical  design  situations,  by 
th-G  time  you  have  produced  this  and  found  out  that  and 
made  a  synthesis,  you  realize  you  have  forgotten  to 
analyze  something  else  here,  and  you  have  to  gc  arxDund 
the  cycle  and  produce  a  modified  synthesis,  and  so  on. 
In    practice,    you    gc   around   several    times. 


Ellinger  stated  that  the  iterative  approach  to  design  ".-- 
is  pariculaily  suited  to  novel  projects  of  some  complexity." 
[Eef .    12:    p.  vi  ] 

Smithies  [Ref.  17]  has  suggested  that  rhere  are  a  number 
of   essential     stages   in   design.  The   first     stage,      design 

analysis,  is  the  statement  cf  the  problem,  ?.  The  nex"c 
stage  consists  of  finding  one  or  more  tentative  solutions, 
IS.  This  sclution  is  then  criticized,  C.  When  the  d*fsigner 
criticizes  the  solution,  he  or  she  admits  that  the  problem 
statement  was  inadeguate.  So,  the  designer  re-states  the 
problem    and   begins    anew. 

E1-TS1-C1-P2-..  .-?n. 

Smithies  attributes  his  views  about  design  to  Pepper 
[Ref.  18].  Popper  believes  that  the  process  or  activity  of 
understanding  can  be  represented  by  a  genaral  scheme  of 
Ii2^J:J2      solving      h^     cojec  tur  e     and      criticism.  Popper's 

scheme,    adapted    by   Scithies,    is   this: 

P1-TT-EE-P2. 

PI  is  the  initial  crcblem  statement;  TT,  the  •tentat:.ve 
theory',  is  the  conjecture.  EE,  'error  elimination',  is  the 
critical      examination  of     the   conjecture.  P2      is   the      new 

problem  statement  which  emerges  from  the  examination.  It 
leads  to  ancther  attempt,  and  so  on  [Hef.  18  :  p.  164]. 
Smithies'  design  stages  and  Popper's  problem-solving  scheme 
are  very  much  like  Polya's  [Ref.  19]  method  for  solving 
problems.  Software  designers  should  take  note:  Polya  is  a 
mathenatician.       Popper  is  a    philosopher,      and   Smithies    is  an 
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architect,      yet    -sach   approaches   the   solution   to  a    prcblsm   in 
the    same    way. 

The  progress  of  the  designer  through  these  stages  is 
marked  by  increased  knowledge  and  shifting  priorities. 
Clearly  that  progress  is  not  linear  and  should  be  called 
evolutionary. 

F.       SDMMABI 

Several  points  about  design  have  been  made  in  the 
proceeding   sections: 

1.  Design  is   symnetrical   and   adaptive; 

2.  The  interesting  (i.e.,  large,  complex)  design  frcblams 
can   be  considered  as    wicked  problems; 

3.  Cc mm uni cations  with  the  end  user  are  crucial  and 
depend  to  a  large  degree  on  pat-erns  which  bridge  the 
communications   barrier    between   designer  and   end    user; 

4.  Design  is  a  learning  process  —  each  party  brings  a 
different  perspectiv  e  to  the  problem  (and  the  solu- 
ticn!)  and  leaves  (or  should  leave)  with  an  augmented 
perspective; 

5.  Design  is  satisficing; 

6.  Design  takes    flace   in   an   organiza-ional  context; 

7.  Design  is  evcluticnary. 

The  separation  of  "chese  poinds  should  not  be  miscon- 
strued. Each  cf  these  aspects  is  interrelated  and  to  a 
certain  extent  mutually  dependent  on  one  another.  When  we 
say  that  design  is  evolutionary,  we  also  imply  that  design 
is  symmetrical  and  adaptive.  When  we  say  that  design  is  an 
organizational  activity,  we  also  imply  that  there  will  be 
extensive   ccmmunicaticn   during   design.  Whenever    we   try   to 

understand  the  problem,  to  learn  mors  about  our  tentative 
solution,  we  are  raising  a  problem  of  understanding,  or 
posing  a  higher  level  problem,  which  implies  that  design 
problems   are  wicked    problems. 
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This  interrelated  set  of  design  elements  forms  the  tack- 
drop  for  the  remainder  of  this  work.  The  following  chapter 
presents  evidence  from  the  literature  that  each  of  the 
design  elements  described  above  is  a  factor  in  software 
design. 
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III.     SOFTWARE    DESIGN    METHODS 

A.       SOFTiARE   DESIGN    IS   SYMMETRICAL   AMD   ADAPTIVE 

Several  instances  in  th€  literature  point  to  the 
symmetry  cf  the  software  design  problem.  That  is,  the  solu- 
tion not  only  depends  on  the  problem,  but  the  problem 
depends  en  the  solution.  Solution  and  problem  are  no*  sepa- 
rare  issues,  rather  they  are  intertwined,  much  like  the 
figure  and  ground  in  a  painting  or  picture.  Each  depends  on 
the  other.  Unfortunately,  most  people  associated  with  soft- 
ware design  do  net  appreciate  this  point.  Peters  points  cut 
that  software  designers  complain  bitterly  that  requirements 
are  poorly  defined  while  customers  and  analysts  often 
complain  that  the  design  is  not  responsive  to  "he  problem  or 
problems  as  they  see  them.  [Ref.  23  :  p.  67].  Peters 
wasn't  tte  first  to  recognize  this,  though.  Podolsky  wrote 
a  humorous  article  in  1977  [Ref.  24]  where  he  states  "Peer's 
Law": 

?e  er j  s   Law 
The    solution    to  a    problem   changes   the   problem. 

Several  ether  authors  [Ref.  25,  26,  and  27]  have  also  recog- 
nized that  the  problem  definition  tends  to  evolve  as  the 
designers  try  to  bound  the  problem,  or  modify  the  require- 
ments. Mccracken  and  Jackson  [Ref.  27]  have  gone  so  far  to 
say  that  this  dependence  is  analogous  to  the  Heisenberg 
Principle:  Any      system      development      activity      inevitably 

changes  the  environment  out  cf  which  the  need  for  the  sys-cem 
arose . 
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Much  affort  is  currently  devotsd  to  requirements  defini- 
tion and  yet  inccmpleteness ,  ambiguity,  and  poor  definitions 
in  requirements  documents  are  often  pointed  to  as  the"  fore- 
most prcblems  facing  software  designers  today.  The  effort 
which  is  spent  on  completely  specifying  the  user^s  require- 
ments  will   gain    nothing   if    software   design    is   adaptive. 

Mccracken  and  Jackson  believe  that  systems  requirements 
can  never  be  stated  fully  in  advance.  To  assert  otherwise 
is  to  ignore  the  fact  that  the  development  process  itself 
changes  the  user's  perceptions  of  what  is  possible, 
increases  insights  into  the  applications  environment,  and 
often  changes  the  environment  itself  [Eef.  27:  p.  31], 
Peters  says  that  although  requirments  may  have  been  very 
fixed  at  the  beginning,  they  tend  to  change  and  evolve  with 
time.  If  for  no  othsr  reason,  the  user's  perception  of  the 
problem  changes  as  dees  the  designer's  perception  of  that 
problem   [Bef.    23:   p,    70], 

Change  is  inevitable  during  software  design,  and  yet 
"planning  for  change"  has  long  bean  given  lip-service,  at 
best.  Neumann  believes  that  planning  for  change  is  slowly 
being  recognized  as  an  important  end  in  itself--and  one  that 
usually  cannot  be  achieved  by  retrofits  into  an  inflexible 
design   [Bef.   28]. 

B.       DESIGN    IS    SATISFICING 

Mcst  computer  system  developers  will  immediately  argue 
this  point.  Developers  of  military  systems  would  argue  the 
longest  and  hardest.  Why  should  the  idea  of  satisficing  be 
so  controversial?  Parhaps  the  answer  lies  in  the  past,  when 
machine  time  was  expensive  and  computer  memory  limited. 
These  limitations  do  not  exist  at  the  same  level  today.  In 
fact,  satisficing  occurs  all  the  time.  Conn  states  that  the 
requirements  for     state-of-the-art  systems   are     often   scaled 
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dcwn  to  respond  to  the  need  to  cut  the  overall  expense  of 
the  project  or  to  meet  time  limitations  [Hef.  26:  p.  '♦03], 
Designers  are,  or  should  be,  constantly  aware  of  the  -trade- 
offs that  are  made  in  systems  development,  especially  the 
classic   trade-off,    ccst   versus   performance. 

Several  authors  point  out  that  a  user  should,  in  fact 
must,  sacrifice  an  cptimum  design  for  a  design  which  can 
cope  at  a  satisfactory  level  [ Bef .  29,  30]-  John  Munsun  has 
been    quoted    as    saying: 

Users  iiii:sx  look  at  the  economics  involved  in  automation 
as  a  software- productivity  solution.  If  a  user  can  buy 
a  payrcll  program  xhat  is  almost  what  he  needs  for 
$10,000  cr  one  that  exactly  fits  his  needs  for  $1 
million-  he  must  look  at  the  trade-offs  and  reduce  his 
expectaticns.      [ Ref .   30   :    p.    66] 

Satisficing  has  to  do  with  more  than  economics. 
Lawrence  Peters  has  said  that  the  trade-offs  for  execution 
efficiency  and  ease  of  change  must  be  evaluated  and  a 
comprcmiss  made.  [Ref.  30].  Lockett  emphasizes  the  role  of 
user  satisfaction  when  evaluating  rrade-cffs.  For  her,  user 
satisfaction  is  not  based  solely  on  the  functional  capa- 
bility of  a  sysrem,  but  on  useability,  reliability,  and 
performance  as  well.  Often  the  user  cannot  have  everything 
(for  example,  both  performance  and  functional  capability)  he 
cr  she  wants  in  a  system.  The  final  product  may  be  the 
result  of  ccmpromise.  Certain  functional  capabilities  may 
te  eliminated  to  achieve  specific  performance  goals  or,  on 
the  other  hand,  the  user  may  be  willing  to  sacrifice 
performance  to  obtain  some  functional  capability  [Ref.  31  : 
p.    157]. 

Several  ether  authors  emphasize  the  role  of  agreement, 
concensus,  and  negotiation  [Hef.  32,  39,  33]-  These  authors 
conxend  that  as  system  design  progresses,  alternatives  are 
proposed    and  evaluated.  The  exact    definition   of      a   system 


27 


may  net  be  as  important  as  the  concensus  on  the  inexact 
definition  which  is  attained.  An  example  from  Land  serves 
to  illustrate  the  inportance  of  sazisficing  in  sofr,vfars 
design: 

.    .    .    .    the  designer  has    to    be   aware  that   building   flex- 
ibility  into,     systems   can      also  be      expensive,       both      in 


to  the  needs  existirg  at  the  time  or  implementation,  tut 
which  may  be  incapable  of  modification,  and  may  have  tc 
be    replaced   if   requirements   change.      [Ref-    29    :    p.    67] 

Satisficing  may  also  involve  psychological  trade-offs  as 
well  as  zechnical  trade-offs.  Madnicic  and  Donovan  reia-e  an 
instance  where  two  possible  algorithms  could  have  b«=en  used. 
The  inefficient  algorithm  was  chosen  because  the  designer 
could   not   stand   the    suspense   of   waiting   [Ref.    22:    p.    U91]. 

C.       SCPTSARE   DESIGN    IS    k    WICKED    PROBLEH 

Hcrsx  Rirrel  has  suggested  -chat  design  problems  are 
wicked    problems      [Ref.    13,      9].  These      problems   are      ill- 

formulated,  have  confusing  information,  have  many  clients 
and  decision-makers  with  conflicting  values,  and  have  rami- 
fications in  the  whole  system  which  are  thoroughly 
confusing.  Peters  and  Tripp  have  suggested  that  software 
design  is  a  wicked  problem.  Th^y  believed  that  a  comparison 
of  the  attributes  and  problems  associated  with  software 
design  and  the  characteristics  of  wicked  problems  make  it 
apparent  that  software  design  is  itself  a  wicked  problem 
[Ref.  37].  A  review  of  the  properties  of  wicked  problems 
and  their  relation  tc  software  design  should  help  tc  put 
this    notion   in    perspective. 
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wicked   iroblams      have   nc      definitive   formal ax ion.  Any 

time  a  foriulation  is  made,  additional  questions  can  be 
asked  and  mere  information  can  be  requested.  Our  inability 
to  define  system  requirements  completely  and  unambiguously 
is  a  symptom  of  this  problem.  Currem:  efforts  in  software 
devalcpment  seem  to  be  aimed  at  the  symptom  rather  than  the 
problem. 

Several  authors  raise  the  possibility  that  a  complete 
set  cf  requirements  is  impossible,  that  a  stat9-cf-the-art 
system  is  almost  by  definition  on>=  for  which  there  remains 
some  degree  of  uncertainty  at  the  time  requirements  are 
preparsd.  Under  these  conditions,  it  is  hard  to  imagine  a 
set  of  "complete"  requirements,  since  the  knowledge  of  the 
eventual  system  at  that  point  can  only  be  incomple-e 
[Ref.    26    :    p.    403]. 

Wicked  problems  have  no  stopping  rule.  Any  time  a  solu- 
tion is  formulated,  it  can  be  improved  or  worked  on  more. 
Cne  stops  only  because  one  has  run  out  of  resouces, 
ps.tienci,  cr  something  slse  ,  Few  would  argu5  -hat  ther==  are 
clear  stopping  rules  for  software  design.  (Else  why  are 
there   innumerable   examples    of   cosu   and   schedule   overruns?) 

Scluxions  to  wicked  problems  cannot  be  correct  or  false. 
They    can      only    be  gocd      or    bad.  This   notion   can      be   quite 

controversial      among      computer        scientists.  Granted,        a 

computer  system  must  work  properly,  especially  in  life- 
critical  cr  lif e-thr satening  circumstances  (hospital  equip- 
ment  or  nuclear  reactors,  for  example).  But  '^work  properly" 
has  different  meanings  to  different  people,  or  groups  of 
people,    just  as    do    "correct"   or   "true".  3       * 


^Mortimer  J.  Adler  discusses  the  idea  of  "truth",  an 
idea  we  judce  by,  in  Six  Great  Ideas,  aacmillan  Publishing 
Co.,    Inc.,    New    York,     1^B7. 
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Perhaps  "good"  and  "bad"  are  poor  choices  as  well,  yst 
most  of  us  readily  acknowledge  the  differences,  when 
presented  with  "good  or  bad,  for  whom?"  The  distinction 
could  be  thought  of  in  terms  of  'technical  success*  and 
•psychological  success'.  Technical  success  is  the  degree  to 
which  the  actual  performance  of  the  system  matches  its  spec- 
ification, while  psychological  success  is  the  degree  to 
which  the  end  user  has  confidence  in  th"*'  final  system 
[Ref.    36]. 

Another  distinction  can  be  made  from  the  observer's 
point   of   view  of   a   system:  a  system   exists  and    is  defined 

by  the  perscn(s)  observing  it.  It  is  as  acceptable,  perhaps 
even  laudable,  as  the  observer  perceives  it  to*  be.  If  a 
system  wciks  in  the  eyes  of  those  who  use  it^,  then  to  those 
users  that  system  is  a  good  one.  Conversely,  if  a  system  is 
cbserved  as  not  working  by  those  same  users,  then  it  is  not 
good  regardless  of  any  ether  attribute  it  may  have. 
[Ref-    33]. 

Ii2  aSlZiM  w ic k e d  problems  thara  is  no  exhaustive  list 
of  adaissable  operations .  Any  conceivable  plan,  strategy, 
or  act  is  permissable  in  finding  a  solution  and  none  can  be 
prescribed  as  mandatory.  Anyone  in  the  profession  car.  see 
that  this  certainly  applies  to  software  design  (granted, 
there  are  at  present  a  finite  number  of  "design  methodolo- 
gies", yet  each  year  this  number  continues  to  increase). 
The  literature  is  replete  with  references  to  design  methcd- 
clogies:  object-oriented    design,         data-or ianted      design, 

design    based  on    finite-state   machines,    and    so   on. 
See    Table   I   for    a   large,      and   certainly    incomplete,      list   of 
design    methodologies. 

Not  only  are  we  faced  with  many  alternatives  for  a 
design  "met hcdolcgy"  ,  but  we  also  are  faced  with  innumerable 
alternatives  for  solving  the  subproblems  in  the  particular 
design   case     at    hand.        There      may  ba      more  than    one      way   in 
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TABLE    I 
C€sign    Hethodologies 

MneiDcriic  Full    Nams   of   Mathodoloqy 

ACM/PCM  Active  and    Passive  Component   Modelling 

DAEES  Data   Oriented   Design 

DSSAD  Data    Structured   Systems    Analysis    and 

Design 
DSSD  Data    Structured   Systems    Development 

EEM  Evolutionary   Design    Methodology 

GEIS  Gradual   Evolution   of    Information    Systems 

HOS  Higher  Order   Software 

IBMFSB-SEP        Adaptation    of    IBM   Federal    Systems   Division 

Software   Engineering    Practices 
lESM  Information    Engineering   Specification 

Method 
ISAC  Information    Systems    Work   and   Analysis 

of   Changes 
JSD  Jackson    System   Development 

NIAM  Nijssen*s  Information    Analysis  Method 

SAET  Structured    Analysis   5    Design  Technique 

SABA  System  ARchitect's   Apprentice 

SD  System  Developer 

SA-SE  Structured    Analysis   and   Structured   Design 

SDM  System  Development   Methodology 

SEEN  Software   Engineering    Procedures   Notebook 

SREM  Software   Requirements    Engineering    Methc- 

dology 
STRADIS  STRuctured    Analysis,    Design   and   Implemen- 

tation of   Information   Systems 
USE  User   Software   Engineering 


which  a  target  system  development  process  can  proceed  simply 
because  there  are  alternatie  approaches  available  at  the 
time  the  requirements  are  written.  A  decision  between  these 
alternatives  may  not    be   possible  [Ref-    26    :    p.    U03]. 

ISI  SJJJI^   wicked      problem   there    is   always      more    than   one 
possible      explanation.  The   selection      of      an      explanation 

depends  en  the  perspective,  or  world-view,  used.  The  expla- 
nation also  determines  the  solution  to  the  problem.  (For 
example,  the  high  cost  of  software  is  often  attributed  to 
labor-intensive  design  and  programming;  poor  requirements 
definition    is  often    blamed    for   software   "failures".) 
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Nc  wicked  £r cblem  and  no  solution  to  it  has  a  definitive 
test.  In  ether  words,  any  time  any  test  is  "successfully" 
passed  it  is  still  possible  that  the  solution  will  fail  in 
some  other  respect.  This  characteristic  of  wicked  prcblams 
is      tied      very    closely      to      the     idea   of      satisfied  ng.  If 

computer  systems  are  tuilt  to  be  flexible,  their  design  must 
fce  generalized.  The  aspect  of  flexibility  is  gained  at  the 
expense   of      efficiency    (not    that      this   is    bad!).  So,      the 

system  "passes"  the  test  for  flexibility  but  is  very  ineffi- 
cient. 

Jl£^  wicked  problem  is  a  "one  shot"  operation.  There  is 
no  room  for  trial  and  error  ,  and  there  is  no  possibility  for 
experimentation.  Many   large-scale      computer  systems      have 

this  characteristic.  In  fact,  software  development  is  some- 
times compared  to  building  a  bridge--once  it  is  built  there 
is  nc  going  back  to  the  beginning  to  redesign  and  rebuild  it 
(for    any    number    of    reasons)  . 

E13.E1   w i ck 6 d      prcfclem   is    unique.  No    two      problems   are 

exactly  alike  and  no  two  solutions  or  strategies  leading  to 
solution  can  readily  be  copied  for  the  next  problem.  This 
characteristic  is  very  evident  in  software  design.  Military 
systems,  for  example,  are  certainly  unique.  Commercial  or 
industrial  problems  are  no  less  unique.  Each  organization 
has  a  unique  structure,  set  of  goals  and  objectives,  set  of 
interactions  with  the  environment,  cast  of  people,  and  set 
of   needs.* 

TJ3€  wicksd  problem  solver  has  no  right  to  be  wrong  -- 
he/she  is  fully  respcnsible  for  his/her  action.  There  has 
been  a  growing  skepticism  among  users  regarding  the  abili- 
ties cf  software  designers.  Users  have  every  reason  to 
believe      that        the      software      designer      "knows"         the      job. 


po 
lems,    for   obvious   reasons. 
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clearly,  the  designer  mast  be  aware  of  many  of  the  factors 
which  could  affect  the  design.  The  designer  must  also  be 
aware  of  the  effects  of  design  decisions-  Allowances  will 
and  can  b€  made  for  unusual  unforeseen  difficulties.  But  to 
hide  behind  the  "This  system  meets  the  specifications  you 
approved  and  signed"  statement  is  going  (and  has  gone)  too 
far. 

D.       COHHONICATIONS    BETWEEN    THE    DESIGNER    AND   THE    END    OSEP 

Perhaps  the  single,  most  widely  noted  problem  area  in 
software  design  is  the  problem  of  communication  between  the 
user  and  the  designer.  The  recent  literature  emphasizes  the 
need  for  extensive  ccmmunications  [Ref-  25,  29,  30,  35,  39, 
and  40]-  The  most  common  reason  given  for  the  problem  is 
that  users  and  designers  speak  with  different  vocabularies 
and    find    it    difficult  to  completely   undersxand   each   crher. 

Much  of  the  literature  which  cites  the  need  fcr  closer 
communication  is  based  on  empirical  and  ancedotal  reports. 
King  and  Hodriquez  [ Bef .  41  ],  however,  report  an  assessment 
of  participation  (and  communication)  in  system  development 
in  an  experimental  context.  The  experiment  tested  four 
specific  hypotheses  (see  Table  II)  about  participative 
design    which  were  stated   in    null   form.s 

The  experimental  results  (see  table  III)  indicate  that 
participative  design  makes  a  difference,  especially  when 
viewing   the    "worth   of  the  system". 


SThis  only  means  that  the  'claim',  i.e..  "accepted 
wisdcm"  in  systems  design,  was  set  up  as  the  alternative  to 
the  hypothesis,  in  accord  with  traditional""  Hypothesis 
testing. 
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TABLE    II 
Hypotheses  Tested   in  the    Experiaent 

HI:      Participation   in   the   dav^lopment   of   rhe    systsm    has 
no   effect  on    the    user's   perception   of   the   worth   cf   the 
sysxei. 

H2:      Participation  in   the   development   of  the   system    has 
no   effect  on    the    amount    of   use   which   is    made   or    the 
systeiE    when    the    user  is    faced    with   strategic    issues    for 
which   the  system    was    designsd   to    provide   support. 

H3:  The  substantive  inputs  provided  by  participants  in 
the  design  process  will  not  be  reflected  in  their  usage 
cf   the    system. 

H4:      The   decision    performance   of   participants    in   the 
design   process   will  not    be   different    from   that 
of   non-participants. 


TABLE   III 
Results  of   the   Experiment 

HI:      The   null  hypothesis    is   rejected. 

This   result    indicates   that    managers    who   are   involved   in 
the    development   effort   tend   to   perceive   the  system   to 
be   more    worthwhile  than    managers    who   are   merely   given   a 
pre-designed    system   to   which   they    had   no   input. 

H2:      Cannot    reject  the   null   hypothesis, 
conclude    that  the    use   of    the   system   in   terms    of   number 
of   queries  is  not    significantly   different    for   design 
participants    and    ncn- par ticipants. 

H3:      The   null  hypcthesis    was   rejected. 

it    indicates    that    the    substantive    inputs   provided    by  the 
participant    group    in  the    design  and   development    phase 
of   the   information   system   are   reflected   in  their 
actual   use  of  the   system. 

H'*:      Cannot    reject  the   null   hypothesis. 
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As    King   and    Eodriquez  put    it,    the 


.  ...  experiment  provides  some  support  for  "participa- 
tive design  theory":  (a)  The  inputs  provided  by  partic- 
ipants appear  to  have  been  made  use  of  in  their  use  of 
the  system,  and  (fc)  some  positive  attitudinal  impact-- 
in  terms  of  systems  "worth" — seems  to  be  achieved 
through   participation.      [ Bef .    41] 


The  experiment  seems  to  confirm  some  deeply  held  convic- 
tions that  participation  in,  and  responsibility  for,  design 
implementaticn  can  result  in  elimination  or  reduction  of 
communicaticn  problems  [Ref.    29:    p.    65]. 

There  may  be  seme  reason  to  believe  that  the  real 
problsm  viith  communication  is  not  whether  it  takes  place  but 
whether  tie  media  of  communication  is  appropriate.  The  fact 
that  the  designer  has  produced  a  comprehensive  specification 
and  that  the  user  has  • signed  off  the  specification  after 
due  study,  is  not  a  guarantee  that  the  designer  has  under- 
stood the  user's  needs,  or  the  user  the  designer's  specifi- 
cation [Eef.  29  :  p.  65].  Stucki  has  suggested  that  charts, 
graphics,  color  pictures,  and  other  aids  should  be  used  to 
enhance  communications  between  users  and  designers;  verbal 
descriptions  alone  are  just  as  inadequate  for  describing 
software  as  they  are  for  an  architect  building  a  house. 
[Ref.  30]-  So,  although  communications  may  be  a  significant 
problem,    its  form  may   be   equally   as    important. 

E.       SCFTUARE   DESIGN    IS   LEARilHG 

Software  design  is  learning,  just  ask  any  experienced 
program    nanager.        They   want      someone    with    design    experience 
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to  head  the  design  team  [Hef-  46],  Without  explicitly 
acknowledging  it,  these  managers  place  value  in  the  ejcperi- 
ence  learned  from  previous  worlc.  This  "learning  from 
doing"  also  takes  place  during  the  design  of  a  system: 

The  reason  for  the  discovery  aspects  of  software  design 
is  the  designer's  learning  curve.  As  the  system  is 
studied,  analyzed,  and  a  design  formulated,  certain 
features  are  recognized  as  needing  attention  while 
others  are  overlocked.  As  it  becomes  ^.j^parent  which 
features  are  lacking,  priorities  shift.   [Her.  37] 

If  we  accept  that  learning  is  an  element  of  design,  just 
how  importact  is  learning  to  design?  In  an  experiment, 
Alavi  and  Henderson  [Ref.  55]  evaluated  two  strategies  for 
systems  development:  evolutionary  and  traditional.  By 
their  definition,  the  evolutionary  strategy  emphasized  the 
role  of  individual  learning.  They  reported  that  the  find- 
ings support  the  hypothesis  that  an  evolutionary  implementa- 
tion strategy  is  more  effective  than  a  traditional  strategy 
[Ref.  55]. 

They  try  to  explain  their  findings  this  way: 

A  model  which  offers  an  explanation  for  the  findings  is 
Kolt'3  experimental  learning  model  [see  Figure  3.1J. 
Kolt  suggests  that  for  a  learner  to  be  effective  he/sne 
must  have  the  ability  to  engage  in  four  types  of  activi- 
ties: (1)  invclveirent  in  new,  concrete  experiences,  (2) 
observation  and  reflection  of  these  experiences,  (3) 
creation  cf  concepts  that  integrate  these  observations 
into  theories,  ana  (U)  usage  of  these  theories  to  make 
decisions  and  solve  problems.  .  .  .  The  evolutionary 
strategy  maps  directly  with  a  starting  point  at  concrete 
experiences.  In  contrast,  the  traditional  approach 
began  with  the  development  of  a  theory.  ...  An  expla- 
nation of  the  findings  may  rest  in  the  support  that  the 
evolutionary  strategy  had  for  the  learning  process. 
CRef-  55] 


This  model  has  some  important  implications  for  soft- 
ware design.  For  example,  the  perspective  or  world-view 
that  the  designers  (and  users)  bring  to  a  project  become 
important   (after  all,   we   are  starting   from   concrete 
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Figure  3.1  Kolb« s  Learning  Cycle  Model- 
experiences).  Greenspan  and  others  believe  that  the  ability 
to  efficiently  design  appropriate  computer  systems  and 
enable  them  to  evolve  over  their  lifetime  depends  en  the 
extent  tc  which  real  world  knowledge  can  be  captured 
[Hef.  tlS].  Wasserman  [fief.  35]  takes  the  thought  further  by 
suggesting  that  memters  of  the  different  groups  concerned 
with  design  perceive  the  function  of  an  information  system 
differently.  Misunderstandings  of  objectives  can  and  do 
occur,    many   times   leading  tc   project    failure. 


37 


Land  [Bef.  29]  also  states  that  there  ara  different 
ideologies  and  perspectives  among  the  different  interests 
involved  in  a  systems  study.  Land  suggests  that  managers 
meet  this  challenge  by  setting  up  a  design  team  which 
contains  representatives  of  all  the  aajor  interast  groups, 
maicing  it  possible  for  the  different  ideologiss  and  perspec- 
tives of  the  participants  to  be  made  explicit,  and  for  the 
different  members  of  the  group  to  learn  ^rom  each  others 
different   viewpoints  [Ref.    29]. 

Hew  migh-c  rhe  participation  of  users  in  the  systam 
design  enhance  oi  promote  learning  and  real-world  knowledge? 
Pobey  [Ref.  42]  conducted  an  experiment  -hat  explored  a 
model  of  constructive  conflict  in  the  MIS  development 
process.  -  His  model  (presented  in  Figure  3.2)  is  described 
here  : 


User  participation  should  lead  to  conflicts ,  which 
should  ""^ITen      "5a        satisfactorily      resolved .  However, 

conflict  and  its  resolution  are  more  Tixely  to  occur 
whan  users  can  exercise  their  influence  in  the  develcp- 
asnt    PICC3SS.  Conflict    itselT"*  '^oas   not      lead   to      i-ts 

rescluricn:  rather  the  increase  in  conflict  makes  reolu- 
ticn  more  difficult.  It  is  only  through  participation 
and  influence  that  conflict  can  ba  successfully  resolved 
in    this   model.      [Ref.    42] 


There        is      other        research        which      supports        Rotey's 
"constructive     conflict".  Boland  [Ref.    54]     compared      two 

different   processes    of  interaction  in   system   design: 

1.  traditional--the  designer  conducts  a  traditional 
interview  of    the   user 

2.  alternative-- the  designer  and  user  share  ideas, 
present  mutual  suggestions,  and  critigue  their 
suggestions. 

His   results   are    significant: 

1.  The  alternative  process  produced  higher  quality 
designs    with    important    implementation  advantages. 
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Figure    3.2        A   Constructive   conflict    aodel    for  User   Involvement. 

2.  The  two  processes  produced  designs  which  used 
different   organizational   con-rol    strategies. 

3.  Different  processes  may  help  to  define  different 
problems  and  thereby  produce  different,  but  squally 
rational,    solutions.      [ Bef .    54] 

Boland   likens  the   prctlem  solving     process    to   a    dance   during 
which   the    designer    punctuates   his     inreraction   with   the   user 
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in  a  series  of  tgaching ,  suggest  inq,  and  critiquing. ^ 
Eoland  asks  us  to  accept  the  notion  of  learning  and  the 
importance   cf  real    wcrld   knowledge: 


Let  us  accept  that  the  viewpoint  and  implicit  models 
held  ty  designers  will  color  their  collection  and  inter- 
pretaticn  cf  data  about  the  needs  of  the  oraanization 
they  are  designing  for.  This  study  suggests  that  under- 
standing how  that  viewpoint  builds  a  coherent  design 
statement  requires  an  understanding  cf  how  the  designer 
interacts  and  exhanges  information  with  his  cli-^^nt.  The 
interaction  prctoccls  may  then  be  seen  as  mediating  the 
process  cf  completing  the  designer's  "point  of  view" 
(creating   the    design  statement).      [ Hef .    54:    p.    896] 


Rcbry's  experiment  lends  support  to  Boland's  findings: 
"It  appears  that  participation  does  lead  to  perceived  influ- 
ence in  .  .  .  system  development"  [Ref-  42].  Robey's  find- 
ings suggest  that  influence  is  used  constructively  to 
resolve  conflict  and  that  users  learn  how  to  exert  influ- 
ence towards  conflict  resolution  as  well  as  conflict  genera- 
tion   as   the    development   process   proceeds   [Hef.    42    :    p.    82]. 

As  we  have  seen,  there  is  support  that  learning,  argu- 
mentation, and  a  designer's  world-view  are  iirpcrtdnt 
elements    in   software    design. 

F.       SCFTSIHE   DESIGN    HAS    AN    ORGANIZATIONAL    CONTEXT 

At  first  glance,  the  casual  reader  is  apt  to  say  "lou 
are  stating  the  obvious."  Yet  much  of  the  current  work  in 
software  design  igncres  the  obvious.  Land  provides  seme 
evidence    for  this: 

1.  Users  are  uncertain  about  the  affect  the  final  system 
will  have  on  their  individual  roles  in  the  organiza- 
tion  and    on    them   personally. 


^Compare  Boland's  "dance"  and  Robey's  "constructive 
conflict"  for  software  design  to  Rittel's  "argumentation"  in 
design    (Chapter    II) . 
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2.  The  cbservaticn  that  the  user  operates  within  formal 
systems  and  that  the  formal  procedure  of  the  existing 
systems  have  teen  overtaken  by  less  formal  (but  often 
mere   effective)    unauthorized   procedures. 

3.  The  fact  that  those  who  are  involved  in  the  analysis 
Ficcess--DP  specialists  and  users — are  often  not 
aware  of  strategic  decisions  made  by  senior  manage- 
ment which  could  have  an  important  bearing  on  the 
workability    of   the  syst9m. 

4.  New  systems  almost  certainly  include  innovations; 
users  and  analyst/designers  cannot  predict  managers* 
responses  to  innovations.  Conjectures  about  peofle^s 
behavior  are  no  substitute  for  knowledge,  and  in 
innovation,  such  knowledge  is  not  ordinarily  avail- 
able.     [Ref,    29:    p.    64] 

Although  Land  cited  these  points  as  reasons  for  communi- 
cations problems,  they  can  egually  serve  as  indictments 
against  current  software  design.  That  is,  organizational 
aspects    cf    software    design    are    often    ignored. 

Wasserman  points  out  that  organizations  and  computing 
environments  are  highly  dynamic  and  that  information  systems 
must  be  designed  for  a  changing  organization  [Ref.  35]. 
Chafin  states  that  as  computer  systems  become  more  deeply 
involved  in  the  operations  of  organizations,  they  have 
larger      social      effects     on      these      organizations.  A      new 

computer  system  may  change  the  organization  structure,  the 
power  structure,  or  the  overall  information  flow  structure 
in   an   organization   [  Hef -    40]- 
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Zmud  and  Cox  rsccgnized  the  organizational  aspects  of 
software  design  in  their  discussion  of  a  "change"  approach 
to  design  and  implementation: 


The  change  approach  to  MIS  implementation  strives  to 
create  an  environment  in  which  change  will  be  accepted 
through   the  active  involvement   of  affected   organiza- 


;y  ^      _     

trust  and  committment  must  develop  between  participants 
so  that  a  free  exchange  of  beliefs  and  opinions  is 
possible.      [Eef-    53   :    p.    37] 


Zmud   and  Cox   make  no      reference   to   wiclced   problems,      yet 
their   change  process   is  recommended      when    (1)      the    organiza- 
tional  activity    involved   is    ill-defined,         (2)      the    MIS   must 
interface      with      other     organizational        systems,         and      (3) 
substantial     organizational      change   is      expected.  Compare 

these  characteristics  to  Horst  Rittel's  characteristics  of 
wicked   problems     (Chapter   II). 

Although  there  are  several  articles  and  references  to 
organizational  aspects  of  software  design,  two  authors  stand 
cut.  Kling  and  Scacchi  have  written  two  extensive  articles, 
[Ref.  59  and  60],  which  stress  the  need  for  an  awareness  of 
and  attention  to  organizational  and  social  aspects  of  system 
design.  Their  latest  work  [Ref.  60],  develops  a  family  of 
models  (called  web  mcdels)  which  they  believe  helps  tc  "make 
tetter  predictions  of  the  outcomes  of  using  socially  complex 
computing   developments".  These   models      are   contrasted     to 

•discrete-entity' — rational  and  traditional — models.  Their 
work  attempts  to  abstract  a  set  of  principles, 
characteristic  of  web  models,  from  analyses  published  in  the 
literature. 
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Kling  and  Scacchi  stress  the  importance  of  perspective 
in  the  "social  analyses  of  ccmputing".  They  identify  six 
perspectives,   four   of   which    predominate: 

1.  Formal-rational 

2.  Structural 

3.  Interact ionist 
U.   Pclitical 

Their  point  in  discussing  these  perspectives  is  that  each 
"casts  a  different  light"  on  the  significant  aspects  of  the 
design  problem. ^ 

Further  discussion  of  the  work  of  Kling  and  Scacchi  is 
beyond  the  scope  of  this  work.  The  point  to  be  made  of 
their  work  is  that  software  design  is  conducted  in  an  orga- 
nizational framework: 

In  contrast  tc  the  discrete-entity  models,  which  gain 
simplicity  by  ignoring  the  social  context  of  computing 
develof ments,  web  models  make  explicit  the  salient 
conections  between  a  focal  technology  and  its  social  and 
political  contexts.  [ Ref •  60  :  p.  3j 


G.   SCFTHiHF  DESIGH  IS  EVOL0TIONA2Y 

Much   cf  the   current   practice  in  software   design  is 

constrained  by  a   model   popularly  termed  the   • waterfall* 

model.    Tcir  Gilb  aptly  sums  up   the  attitudes  of  most  soft- 
ware professionals: 

It  seems  that  they  recognize,  as  yet,  only  one  tyoe  of 
life  cycle.  In  particular,  they  seem  to  be  speaking  of 
a  revolutionary  life  cycle  (like  the  birth  or  a  human) 
as  opposed  to  a  mere  evolutionary  life  cycle  (such  as 
the  development  of  the  human  species).   [Ref-  34j 


'Kling  and  Scacchi  present  an  extensive  discussion  of 
the  social  dynamics  cf  system  design  in  [Bef.  59].  Their 
discussion  is  based  on  the  four  perspectives  mentioned  as 
well  as  two  others:   human  relations  and  class  politics. 
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ether  authors  also  complain  about  the  current  life  cycle 
model.  Brittan  is  concerned  that  the  serial  definition  of 
the  project  development  cycle,  known  as  the  linear  strategy, 
embodies  cne  fundamental  concept:  that  an  activity  follows 
logically  from  its  predecessor  so  that  each  stage  is 
complete   before      the   next  begins   [Ref.    36]-  McCracken   and 

Jackson  seem  to  be  the  most  critical  of  the  current  life 
cycle  model.  They  believe  -chat  any  form  of  life-cycle  is  a 
project  management  structure  imposed  on  system  development. 
Furthermcrs,  they  fcint  out  that  the  current  life  cycle 
modal  is  either  a  very  much  simplified  model  (which  is 
worthless)      or      unrealistic    [Ref.    27].  Podolsky   [Ref.    2^*  ] 

argues  that  the  current  model  (which  he  terms  'Classic 
Development')  is  "very,  very  good"  when  it  is  successful, 
but  thax  when  it  fails,  "it's  horrid".  He  attributes  the 
success  and  failure  cf  Classic  Development  to  the  type  of 
problem    which  will    be   solved:  classic   development   is  good 

for  well-defined,  highly  structured,  change-resistant  prob- 
lems; it  fails  when  presented  with  an  ill-defined  prcblem, 
changing        participants,  and        changing  requirements. 

Zvegintzov  [Ref.  57]  has  twc  objections  to  the  current  life 
cycle  mcdel.  First,  it  does  not  portray  a  systems  life, 
only  the  creation,  development,  or  youth  of  a  system.  It 
does  not  include  adulthood  and  is  vague  about  operation  and 
maintenance.  Second,  it  is  noz  a  cycle,  it  portrays  a 
linear  path  and  does  not,  as  a  cycle  must,  return  tc  its 
beginning  [Ref.  57].  Gladden  even  goes  so  far  to  say  that 
the  software  life  cycle  may  be  harmful  to  the  software 
profession.      See   Figure   3.3    for   Gladden's    representation. 

These  arguments,  and  others,  begin  -co  raise  a  question 
about  the  validity  of  the  linear  strategy.  The  linear 
strategy  places  a  great  deal  of  reliance  on  the  studies  and 
efforts  lade  in  the  earlier  'stages'  of  software  develop- 
ment.        Yet   this   strategy   ignores  the    fundamental   aspects   of 
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Figure  3-3        Typical    Life  Cycle  Sepresentation, 
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design      described      ir     Chapter      II.  Brittan      places      this 

predicanient   in    perspective: 


In  a  majority  cf  cases,  particularly  when  the  organiza- 
tier.  lespcnsible  for  designing  ana  implementing  the 
system  has  experience  of  similar  systems  and  when  the 
users  are  clear  about  what  taey  want,  the  linear 
strategy  is  pefectly  satisfactory  and  produces  gcod 
regults.  Too  often,  a  project  starts  on  the  linear 
strategy  but  the  initial  requirement  is  vague,  over- 
ambiticus  or  fails  to  meet  the  real  need:  in  fact  the 
requirement  is  still  fluid.  The    project   then    proceeds 

in  a  series  of  shcit  locps  as  the  requirement  solidi- 
fies.   .    .    .      [Bef.    36] 


Now  it  becomes  clear  why  Gladdan's  representation  in  Figure 
3.3  appears  as  it  does.  To  make  up  for  the  reality  of  soft- 
ware design,  the  practice  is  to  use  a  'loopy  linear* 
strategy.  That  is,  to  proceed  in  a  series  of  relatively 
haphazard   and  short-term  locps.      Again    from   Brittan: 

Some  loops  are  inevitable-  One  of  the  symptoms  of 
excessive  loopiness  is  a  feeling  of  antipathy  between 
the      different     grcups     associated        with      the      project. 


.n  g    what      -  n  e  y 

be  anncyed  by  the  apparent  lack  of  good  project  manage- 
ment as  the  system  overruns  its  budget  in  both  time  and 
cost.      [Ref.    36] 


Brittan    gives  other    reasons    why  the   linear    strategy   is    pocr: 

1-      when   analysts     refine   the      requirements  of      a   system, 

their  investigations    and  studies      frequently    threw   up 

problems    which   were    not    suspected   at   the    outset. 

2.      the   linear   strategy    can   only      be    based  on    studies   and 

investigations  made    by    analysts;    users,    who   determine 

the   success    of   the  system,        are   not   usually    adept   at 

the   conjecture  and  extrapolation   needed  to    understand 

these  studies. 

Land   [Ref.    29],    Brooks  [Ref.    46],      Podolsky  [Ref-    24],      Zave 

[Ref..    32],      and    Lehman  [Ref.    47],      to      name   a    few,       have    all 

argued   that     a    system  will    require      substantial,      continuing 
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changes  after  the  client  begins  to  use  the  system.  We  tsnd 
tc  relegate  this  phenomenon  to  *  Maintenance* .  But  this 
isn't   enough.      Consider   this  comment    by   Land: 

The  conventional  model  of  the  systems  life  cycle  assumes 
that  an  analysis  and  feasibility  stage  precedes  the 
detailed  design  stage  and  that  this  will  be  followed  by 
a  specificiaticn  and  agreement  of  the  specification  for 
the  system.  At  that  point  the  design  of  the  system  is 
often  frozen.  For  a  typical  information  system  the 
staaes  precedina  the  design  freeze  take  between  20^  and 
35  ?{  of  the  total  time  required  for  the  develoment  of  the 
system.  For  between  65%  and  80%  of  this  time  the  design 
of  the  system  is  not  to  be  modified,  even  though  tne 
"world"  is  changing  all  the  time.  In  practice,  even  a 
frozen  design  gets  modified  if  the  system  is  seen  tc  be 
becoming      irrelevant     to    real      requirements.  Further, 

inconsistencies  in  design  are  discovered  during  the 
construction  chase  as  a  result  of  "systems  queries". 
[Ref.    29    :  p.    58] 


Software  design,  no  matter  how  hard  we  try  otherwise,  is 
simply      net    linear.  The      literature      clearly   supports     an 

evolutionary  strategy,  yet  our  practice  has  not  recognized 
this. 

H.       SUHHABY 

The  preceeding  discussion  shows  that  there  is  support  in 
the  literature  for  reassessing  our  view  of  software  design. 
Software  design  is  symmetrical,  but  we  currently  do  little 
to  recognize  that  symmetry.  Software  design  is  satisficing, 
yet  there  is  constant  amphasis  on  optimization,  often  for 
its  own  sake  and  forsaking  approaches  that  enhance  th^ 
useability   or     quality  of  the   software.  Perhaps,      without 

consciously  noting  it,  we  are  also  concerned  with  the  "test" 
design  and  dooming  the  project  to  mediocrity,  at  best,  and 
perhaps   catastrophe. 

Software  design,  especially  for  large-scale  systems,  is 
certainly  a  "wicked  problem."  All  the  evidence  is  there;  it 
only  remains  to  acknowledge  that  fact.  We  are  well  aware 
that      communications      between      the      designer      and      user      are 
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all-impcrtant.  Yet,  we  have  not  really  given  much  thought 
to  the  medium  of  exchange.  Software  design  is  a  learning 
experience.  Designers  learn  that  projects  are  more  complex 
than  expected  and  users  learn  never  to  trust  designers. 
This  may  he  a  harsh  critique,  but  the  point  is  well  illus- 
trated: all  parties  gain  something  from  the  experience  of 
software   design.      Let   us   recognize  the   worth   of   this- 

Tfce  organizational  context  of  software  design  has  long 
been  ignored,  particularly  in  military  systems.  We  must  not 
forget  that  the  computers  are  to  help  the  people  in  a  system 
l2  ESlJSIJ  well,  not  to  control  the  people  as  a  part  of  the 
system.  Finally,  we  are  beginning  to  racognize  that  soft- 
ware design  is  evolutionary.  There  really  is  no  "snd"  to  a 
projecx,  simply  a  restatement  of  rhe  goals  originally  iden- 
tified. 

although  seven  characteristics  have  been  seated  and 
discussed,      their      irterdependencies   are  obvious.  Non-^   of 

these  characteristics  is  munually  exclusive  of  another. 
Rather,  €ach  builds  en  the  ether.  Although  there  ar«  innum- 
erable implications  in  that  statement,  the  remainder  of  this 
work  will  examine  one  approach  which  may  help  us  to  consider 
the    sever   characteristics  of   design   in   software    design. 
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lY.    THE    SOFTWABE    PROTOTYPE 

A.       IHTBCDOCTION 

For  the  last  35  years,  systems  software  developicent  has 
taen  based  en  the  sc-called  •system  development  cycle.*  As 
shown  in  the  last  chapter ,  there  are  several  arguments 
against  such  a  cycle.  Perhaps  the  most  -ailing  argument 
lies  in  cur  process  controls.  Several  authors  [Hef.  61  , 
62]  have  pointed  out  that  in  response  ro  uncertainty  and 
increased  complexity,  there  is  a  tendency  to  define  and 
structure  (and  increase!)  management  controls. 

Correspondingly,  precise  requirements  definitions  have  been 
emphasized.  Berrisford  and  Wetherbe  [Ref.  61]  believe  that 
there  is  a  major  conceptual  flaw  in  the  traditional  view  of 
systems   development.  This   is      that   system     design   assunies 

that  management  knows  what  information  is  needed  and  it  is 
difficult,  if  net  unrealistic,  to  ask  managers  to  d<=fine 
their   information   requirements   on   paper. 

Hew  do  software  designers  cope  with  this  problem?  Rich 
and  Waters  [Ref.  63]  have  explored  this  luestion  and 
theorize  that  software  designers  cope  with  complex  design 
problems  by  using  several  mental  tools,  one  of  which 
involves  simplifying  assumptions.  The  use  of  simplifying 
assumptions  is  both  necessary  and  commonly  used  when 
constructing  large    and  complex   systems: 

Given  a  ccmplex  programming  problem,  expert  programmers 
typically  choose  simplifying  assumprions  which,  thouah 
false,  allow  them  to  arrive  rapidly  at  a  program  which 
addresses  the  important  features  of  the  problem  without 
beina  distracted  by  all  of  its  details.  The  simplifying 
assumptions  are  then  incrementally  ^retracted  with  corre- 
sponding lEodif icaticns  to  the  initial  program.  Often 
the  mam  questions  can  be  answered  using  only  the 
initial    program.       [Ref.    63    :    p.    150] 
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This  us€ *  of  simplifying  assumptions  in  software  design 
is  very  much  like  the  idea  cf  the  tentative  solution,  -  which 
was  introduced  in  Chapter  II.  Such  a  tentative  solution  is 
only  a  simplified  system.  Earl  [Ref.  64]  calls  these 
simplified  systems  prototypes.  Carrying  this  one  step 
farther,  Naumann  and  Jenkins  define  a  prototype  system  as 
"a  system  that  captures  the  essential  features  of  a  later 
system."        [Bef.    62].  The      sections        wnich      follow      will 

describe  the  prototype  process,  the  role  of  prototypes  as 
models,  the  ways  in  which  prototypes  are  used  and  concludes 
by  showing  how  the  set  of  seven  desing  elements  are 
supported   by  software   prototypes. 

B.       THE    PEOTOTYPE    PROCESS 

The  terms  protctype  and  prototype  systems  have  become 
rather  ccmmon  lately,  found  in  both  the  management  litera- 
ture (Harvard  Business  Review,  for  example)  and  the  software 
engineering  literature  (proceedings  of  conferences  and  work- 
shops especially).  Although  i:he  term  prcnotype  has  become 
standard,  early  descriptions  of  the  process  were  called 
"heuristic        development"        and  "iterative        enhancement" 

[Ref.    61,    65]. 

Regardless  of  how  each  of  us  may  use  the  term,  there  is 
general  agreement  that  the  main  purpose  of  prototype  systems 
is  exploration  and  experimentation;  "the  aim  of  the  early 
prototype  is  to  learn,  to  find  out,  to  discover."  [Ref.  68, 
64,  66]-  In  keeping  with  their  purpose,  prototypes  are 
relatively  inexpensive,  flexible,  and  simplified  systems. 
Bally,    Brittan,    and    Wagner    describe   the    prototype    process: 

In  the  prototype  strategy,  an  initial  and  usually  highly 
simplified  prototype  verson  of  the  system  is  designed, 
implemented,  tested  and  brought  into  operation.  Based 
on  the  experience  gained  in  rhe  operation  of  the  first 
prototype,  a  revised  reguirment  is  esrablished,  and  a 
second  prototype  designed  and  implemented.  The  cycle  is 
repeated      as      often        as      is      necessary      to        achieve      a 
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satisfactcry  operational  system,  bearing  in  mind  the 
possibly  escalating  cost  or  each  subsequent  cycle;  it 
may  welj.  be  that  orly  one  prototype  is  necessary  before 
producing   the    final  system.      [ Bef .    68:    p.    23] 

From   this  description,    four   steps   are   evident   [ Ref -    62]: 

1.  Identify    the    user's    basic   information   requirements. 

2.  Develop    a  working   prototype. 

3.  Iirplement  and    use  the   prototype. 

4.  R€vis€  and  enhance  the    prototype. 
Figure   4.1    illustrates  the    prototype    process- 

A  prototype  system  must  be  implemented  quickly,  perhaps 
in  hours  or  days,  certainly  no  more  than  two  or  thrae  weeks. 
The  advantage  here  is  in  the  user-designer  interactions: 
the  user  is  given  a  working  system  to  operate  and  criticize, 
the  designer  receives  responses  based  on  the  user's  experi- 
ences. The  quick  response  of  the  designer  guarantees  that 
the    first      prototype   will      be    incomplete.  This   aspect      is 

important:  there  is  an  explicit  understanding  between  the 
user  and  designer  that  zhe  system  will  be  incomplete,  that 
a  prototype  is  msant  to  be  modified,  expanded,  supplemented, 
or    supplanted  [Ref.    62]. 

C.       PBOTCTYPES    AS    MOCFLS 

Many  authors  consider  prototypes  to  be  models  [Ref.  64, 
82r  69].  As  models,  prototypes  reduce  risk  and  test  alter- 
native   designs    through  live   operation.      [Ref-    64]. 

Three  aspects  of  prototypes  as  models  are  imporxant. 
First,    models   are   abstract: 

The  critical  skill  cf  system  design  is  .  .  .  claimed  tc 
be  explication  of  the  implicit  models  in  managers* 
minds,  of  their  decision-makina  processes  and  views  cf 
their    organisation   and   environment.      [Ref.    64    :    p.    163] 
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Figure    1.1        The   Prototype   Model. 

Second,  managers  prefer  siaiple  modals  at  first.  As  they 
begin  to  understand  the  models,  they  become  involved  with 
the  design  and  implementation  to  build  more  realistic 
systems.      [Bef.    6U]. 

Third,  a  prototype  is  subject,  to  modelling  effects. 
That  is,  as  a  model,  the  prototype  is  only  a  limited  version 
of  the  final  system.  So,  a  prototype  is  one  kind  of  scale 
model,  accurate  in  some  ways,  inaccurate  in  others 
[Ref.    69]. 
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D-       STBATEGIES    TO    PROCOCE   PHOTOTYPES 

Three    strategies    are   generally      recognized  for    producing 

prototypes,    1)     methodologies    (in   current   use)  ,  2)     executable 

specifications  (state-of-rhe-art  and  research  issues) ,  and 
3)    automatic  programning    (a    research    topic) . 

''  •      I^S    'Methodolcqy  *   Strategy 

There  are  three  basic  methodologies  which  are  used 
to  produce  software  prototypes.  First,  in  screen  and  repcrt 
formatting,  the  designer  produces  a  set  of  user  interfaces 
which   will      be    similar     to    the      final   sys-em.  Second,      in 

partial  and  incomplete  implementation,  the  designer  and  user 
identify  only  a  subset  of  the  total  problem.  Third,  for 
selective  iiplementation ,  the  designer  develops  components 
of  The  final  system  and  then  integra"te  the  components. 
[Ref.    71] 

2  •      Hxecutable    S£6ci fie ations 

The  executable  specification,  -he  second  tschnigue 
for  prototyping,  is  a  current  'hot'  ropic  in  the  computer 
science   literature.  Davis   [ Hef .    72]   describes      a    software 

tool,  the  Feature  Simulator,  which  "executes"  formally 
writter  requirements  specifications  for  real-time  systems. 
Feather  [Ref.  73]  proposes  a  methodology  for  developing 
prototypes  from  specifications  based  on  the  transformation 
of  "specification  constructs"  into  an  implementation. 
Perhaps  the  most  ambitious  work  on  executable  specifications 
is  that  reported  by  Cohen  and  others.  They  believe  that  "a 
prototype  serves  to  mitigate  both  imperfect  communication 
and    lack   of    forsight     (sic)."      [Ref.    74] 

Ihe  solution  Cchen  and  others  have  adopted  separates 
the  imperfect  communication  and  lack  of  foresight  issues  by 
having   a      formal   specification   language      which   unambigiously 
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describes  systems,  and  a  separate  tool  (symbolic  execution 
system)  which  helps  the  reader  to  understand  any  particular 
specification.  This  tool  can  be  used  by  the  specification 
writer  to  validate  the  specification  and  by  the  implsmentor 
(or  buyer)  to  understand  what  exactly  has  been  specified 
(i.e.,  hew  the  pieces  interact).  "Given  the  specification 
and  the  tool,  a  prototype  will  not  be  needed."  That  is,  if 
the  designers  can  ccmpletely  specify  the  requirements  and 
they  then  use  the  symbolic  execution  system,  Cohen  and 
others  believe  that  ii:  is  no  longer  useful  to  develop  a 
prototype . 

Eut  consider  the  following  comment  by  Taylor  and 
Standisb: 

.  .  .  .  having  a  precise  specification  language  is  of  no 
help,  since  tha  user  really  doesn^t  know  what  statements 
to  make  in  such  a  language —  that  is,  he  can't  articu- 
late his  needs  if  he  doesn't  know  what  they  are  reaard- 
less  of  whether  or  not  there  is  a  precise  language  for 
stating  them.      [Hef.   78   :    p.    160] 

Executable  specifications  clearly  are  controversial, 
especially  when  they  concern  prototypes.  Whether  such  a 
technique  gains  prominence  will  depend  on  advances  in  soft- 
ware   engineering   tools. 

3  •      Autcnatic   Prcgramming 

Automatic  programming  is  probably  farther  away, 
technically,  than  the  exacutable  specification.  Automatic 
programming  can  be  thought  of  as  programs  that  help  people 
write  programs.  The  general  goal  of  automatic  programming 
is  tc  allow  the  software  designer  to  think  cf  the  problem 
abstractly,  in  a  way  which  is  natural  and  comfortable. 
Automatic  programming  systems  are  characterized  by  specifi- 
cation methcds  (formal,  'by  example',  or  natural  language), 
the   target    language    (the   language   in    which   the  system    writes 
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ths  finished  program) ,  the  problem  area  (area  of  intended 
applicazicn) ,  and  the  method  of  operation  (theorem-proving, 
program  transformation,  knowledge-engineering,  or  tradi- 
tional ficblem  solving)  [Ref*  100].  One  advantage  cf  auto- 
matic programming  is  that  it  could  allow  for  more 
informality  than  an  executable  specification  language 
[Ref.    70]. 

E.       OSES    CF    PROTOTTPIS 

Generally,  there  are  three  uses  of  prototypes,  1)  to 
clarify  user  requirements,  2)  to  verify  the  feasibility  of  a 
design,    and   3)     to   create  a    final   system.      [Ref.    75]. 

1 .      To   Clarify    the  J se r  * s   Requirements 

Ey  far,  the  most  popular  use  of  prototypes  is  to 
clarify      the     user's        requirements.  McCracken      [Ref.    67] 

believes  that  traditional  written  specifications  do  not 
bridge  the  communications  gap  between  the  designer  and  the 
user.  He  states  that  prototypes  en  courage  users  to  change 
their  minds  about  what  they  want,  until  the  system  is 
useful. 

To  highlight  the  problems  encountered  in  require- 
ments documentation.  Mason  and  Carey  [Ref.  76]  make  a 
distinction   among   three   types   of    documentation: 

1 .  A      textual  list      of    requirements      (the   most      commonly 
used) 

2.  An   interpretive  model    (gaining      in    popularity,      espe- 
cially  in   military   systems) 

3.  A    working  model — a   prototype 

The  textual  list,  the  traditional  method  of 
describing  requirements,  has  a  distinct  disadvantage.  There 
is  a  psychological  distance  between  a  textual  list  and  what 
the    users   will   eventually  receive.      A   lengthy    (often    boring) 
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document  does  not  easily  convey  a  realistic  ssnse  of  hew  the 
system   will   operate    and   suit   the   user's   needs  [Ref-    76.]. 

Interpretive   models      include   SADT      and  USE.  Th=se 

models  use  top-down  decomposition  to  manage  the  complexity 
cf  large  systems,  Ihe  more  detailed  these  tools  are  (or 
become),  the  mor^  specialized  the  language  used.  This  pres- 
ents   a   significant    learning    burden  to   the   user  [Ref.    76]. 

Erotctypes,  en  the  other  hand,  present  a  more  real- 
istic view  cf  the  system  to  the  users.  The  users  can  easily 
relate  their  experience  with  -he  prototype  to  thair 
requirements. 

2-      12   Verify  the   Feasibility   of    Design 

When  prototypes  are  used  to  verify  the  feasibility 
of  a  design,  the  designers  and  users  are  evaluating  the 
internal  design  of  the  software  [Ref.  75].  After  the  proto- 
type is  developed,  several  aspects  of  the  design  could  be 
evaluated:  the  prototype  could  be  used  to  implement  and 
evaluate  certain  design  decisions;  the  prototype  could  be 
used  to  develop  and  test  a  production  system;  the  efficiency 
cf  the  prototype  could  be  examined;  or  the  prototype  could 
be  developed  on  one  machine,  and  the  final  system  imple- 
mented en  the  target  (or  production)  machine,  when  it 
becomes    available. 

3 •      I5   Create  the   Final    System 

Prototypes  may  be  used  to  create  the  final  system. 
This  means  that  part  or  all  of  the  final  version  of  the 
prototype  may  beccme  part  of  the  production  system 
[Ref-  75]-  Examples  of  this  technique  might  include  data- 
base managenment  system  (DBMS)  applications.  For  example, 
once  created,  the  prototype  might  remain  unchanged  espe- 
cially if  the  system  efficiency  is  satisfactory.  On  the 
other   hand,    critical    (or  perhaps    all)     of   the   system   would   be 
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r€Cod€d    for   efficiency,      either   in     the   DBMS   language,      in  a 
host    language,    or   in   assembly   language. 

F.       FBOICIYFES    ADDRESS   THE    ESSEITIAL    DESIGN    ELEMENTS 

''  •      Prototyping    is  a   Symmetrical    and   Adaptable   Process 

Prototypes  explicitly  address  the  symmetry  and  adap- 
tation necessary  in  software  design.  Naumann  and  Jenkins 
[Ref.  62]  believe  that  prototypes  provide  an  appropriate 
response  to  changes  in  the  development  process  (protlems  to 
solve  and  available  resources)  as  well  as  to  changes  in  the 
environment.  Bally,  Brittan,  and  iJagnar  state  that  the 
prototype  strategy  is  an  admission  of  failure,  an  admission 
that  there  will  be  circumstances  when  we  will  be  unable  to 
develop  the  right  system  on  the  first  attempt  [Hef-  68]. 
Earl's  comment  perhaps  best  expresses  the  overall  idea  of 
symmetry   and  adaptation: 


The    prototype    3ysts=ni   .    .       .  allows    .       .      .       d^siar.    bj 

discovery  as  much  as  by  prediction,  where  the  unexpectea 
results  niay  be  as  significant  for  design  as  the 
expected,     (emphasis  added)    [  Bef .    64    :    p.    166]. 


2-      Prototyping    'Tames'    the   Wicked  Problem 

In  Chapter  II  wicked  problems  were  described  as 
problems  where  the  information  is  Gonfusi::ig,  where  there  are 
many  clients  with  conflicting  values,  and  where  the  raniifi- 
caticns  in  the  whcle  system  are  thorougly  confusing. 
Compare  those  characteristics  to  the  experiences  of  Asner 
and    King: 

.  .  .  .  the  prototype  approach  works  when  users  do  not 
know  their  specific  requirements,  [where]  the  effective- 
ness of  any  on  particular  approach  cannot  be  easily 
assessed  without  rsal-life  experience,  .  .  .  [where] 
the  system  will  be  an  integral  part  of  the  day-to-day 
activities  of    the    users.     .    .    .      [Ref-    79    :    p.    30] 
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Developing  prototypes  does  more  than  recognize 
wicked  frcblems.  The  designers  and  users  of  prototypes 
explicitly    acknowledge  such   things  as: 

1.  Wicked  problems  have  no  definitive  solution  —  as  Eally 
and  others  have  stated,  prototypes  are  an  admission 
that  more  questions  can  be  always  asked  and  more 
information    can  be  requested. 

2.  Every  fornulaticn  of  the  wicked  problem  corresponds 
to  the  foriulation  of  the  solution  (and  vice 
v€rsa)--there  is  an  explicit  understanding  between 
the  desinger  and  user  about  basic  assumptions  that 
will  be  made  when  designing  a  prototype,  especially 
the  first  version;  the  protcype  strategy  is  designed 
tc  cope  with  a  fluid  situation  and  fuzzy  requirements 
[Bef,   68]- 

3.  Wicked   prcblens  have    no      stopping   rule — designers   and 
users     realize     that    prototypes      may      be      continually 
modified    or    refined    until      some   exxernal   limit    (time, 
resources,    production   need,    user    satisfaction,      etc.) 
is   reached. 

U.  Solutions  to  wicked  problems  cannot  be  correct  or 
false.  They  can  only  be  good  or  bad--protctyping 
explicitly  recognizes  the  notions  of  "technically" 
correct  and  "psychologically"  correct.  Users  contin- 
ually ask  for  refinements  until  they  become  satisfied 
(i.e.,  where  the  system  is  technically  and  psycho- 
logically correct) . 

5.  In  solving  wicked  problems  there  is  no  exhaustive 
list  of  adiiissable  operations — prototypes  allow 
designers  and  users  the  freedom  to  explore  and  exper- 
iment. 

6.  No  wicked  problem  and  no  solution  to  it  has  a  defini- 
tive test —  designers  and  users  become  quickly  aware 
that     prototypes     clearly    identify      tradeoffs.  The 


58 


pictctype   may   te   flexible   and    sacrifice    (i.e.,    "fail" 
the    test    for)     efficiency. 

3*      Software  Prototyping   is   Satisficing 

Recall  from  Chapter  II  Simon's  argument  that  people 
accept  alternatives  which  are  good  enough,  not  because  they 
want  to,  tut  because  they  have  no  choice.  In  Chapter  III 
evidence  was  presented  which  clearly  shows  that  software 
designers  constantly  balance  trade-offs  and  are  fcrced  to 
accept  satisfactory  alternatives,  rather  than  an  optimal 
alternative. 

The  process  cf  developing  a  prototype  explicitly 
deals  with  satis ficing  by  recognizing  the  interaction  among 
the  user,  designer,  and  system.  Conflicting  goals  and 
priorities  are  inevitable.  Negotiation  between  the  designer 
and    user   will   lead    tc  a   satisfactory    system. 

In  the  prototyping  process,  the  designer  constructs 
successive      versions        of      the      system,  compromising      and 

resolving  conflicts  tetw^ien  "che  context  (-hat  is,  user  n9€ds 
and  desires)  and  the  form,  as  constrained  by  technology  and 
economics   [Bef.    62    :    p.    37]. 

^  -      Prototyping    is  Communicatinq 

The  prototype  facilitates  communication  between  the 
designer   and     the   useri  The    basic      model   of     the    prctoype 

process  shows  that  ccmmunication  is  a  necessary  element  of 
the  process.  Without  communication  there  is  no  prototype. 
Mason  and  Cary  £Ref.  76]  believe  that  prototyping  overcomes 
the  fundamental  problems  of  ccmmunication  between  users  and 
designers.  Naumann  and      Jenkins     [Bef.    62]   emphasize      the 

roles  participants  have  and  believe  that  prototyping 
stresses   the  interactions   between   the   user    and  the   designer. 
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Farticipatior     in      software   design      can      be      pai^.ful 
[Ref.    6  4],    yet 


Users  play  more  active  roles  in  prototyping  than  is 
possible  with  traditional  development  methods.  Users 
set  the  development  pace  by  the  time  they  spend  using 
and  evaluating  the  prototype.  They  decide  when  the 
cycle  cf  evaluation  and  refinement  ends.  [Ref.  62  :  p. 
37]  L  r 


The  prototype  approach  exploits  the  interaction 
between  the  designer  and  user.  Contrast  this  with  the  care- 
fully  mcnitored    interaction    in   the  tradirional  approach. 

5.      The    Software    Prototype   is  a   Learning    Aid 

Several  authcrs  [Ref.  64,  68,  66]  agree  that  the 
very  purpose  of  the  prototype  is  to  allow  the  user  tc  learn 
about  the  system;  experience  with  the  system  is  the  most 
valuable   product.  When   prototyping,        both   designers      and 

users  learn,  developing  a  system  which  is  more  realistic  in 
its  econcmic  purpose,  organizational  context,  and  technical 
performance   [Ref-    64    :   p.    166]. 

Earl  [Ref.  64]  believes  that  prototype  systems 
permit  action  learning  and  that  there  are  few  other  vehicles 
available  for  live  and  flexible  organizational  development. 
As   a    vehicle  for  learning. 


.  .  .  .  the  protoype  model  is  the  most  effective  repre- 
sentation possible  since  it  enables  evaluation  of  the 
proposed  design  in  con-cext .  The  prototype  model  is  the 
representation  tEat  an"^cipates  evaluation  of  the  design 
in    its   operating    environment.      [Ref.    62    :    p.   33] 
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6  •      lii   Ft  o  t  ot  y  p  €     Processs   Accounts      for  Organizational 
Issues 

As  pointed  out  in  Chapter  III,  the  organizaitcnal 
context  is  an  important  consideration  in  systems  and  soft- 
ware desicn.  Informal  organizational  structures  and  the 
sub-elements  of  organizations  play  large  roles  in  the 
success  cr  failure  of  a  system.  As  an  experiment,  the 
prototype  provides  an  opportunity  to  test  the  impact  of  a 
systeu  and  experiment  en  the  organization's  interfaces,  at 
least  reducing  the  risk  of  a  nonviable  system  and  also 
providing  opportunities  for  introducing  and  monitoring  job 
satisfaction  improvements,  organization  development,  and  the 
like  [Ref.  6U:  p,  164].  Earl  believes  that  prototypes  are 
relevant  to  organizations  because  of  individual  differences 
among    pecple  in    the    organization: 

-  .  .  .  the  prototype  methodology  mav  be  relevant,  for 
different  values,  perceptions  and  perspectives  do  exist 
■  among  different  interest  groups,  but  the  different 
implications  and  impact  of  a  system  design  mav  net  be 
apcrsciated  until  it  is  implemented;  indeed'all  the 
options  may  not  be  apparent."  With  a  working  prctotvpe 
system  design  values  mav  be  explicated  and  stakehciders 
counter  the  technical  thrust  of  the  specialists.  . 
[R€f.    64    :   p.     165] 

To  say  that  prototyping  "solves"  the  organizational 
issues  in  software  design  is,  however,  going  too  far. 
Prototyping  deals  explicitly  with  the  issues,  yet  requires 
quite      a   bit     of   "orchestration".  The      management   cf      the 

process   is  not    without  political   consequences  [Ref-    66]. 

Hew  do  we  measure  the  worth  of  a  prototype  as  it 
contributes  to  our  design  of  software?  Earl  answers  this 
question   with  the   following    statement: 


Possibly  the  most  valuable  contribution  of  the  prototype 
methcdclogy  is  to  foster  a  climate  of  system  apprecia- 
ticn,  user  creativity  and  experimentation,  intelligent 
use   and   organisational   learning.      [ Ref .    64    :    p.    166] 
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"^ »      li®   Prototype  Process    is    Evolutionary 

That  the  process  of  protoyping  is  incremental  and 
evolutionary  shold  ccne  as  no  surprise.  The  important  point 
is  that  the  prototype  process,  again,  explicitly  deals  with 
the    issue.  Software  design      has  been      shown   to      be   evolu- 

tionary, yet  traditional  software  development  is  unable  to 
deal    with   it.  Naumann   and   Jenkins   [Ref,    62]     state,      as   a 

•principle',  that  "[p]rot otyping  represents  and  parallels 
the  dynamic  process  of  growth,  change,  and  evolution 
existing   in   any    living  system." 

A  survey  of  the  literature  reveals  an  interesting 
pattern   among     the    models      for   prototyping.  Although   most 

authors  will  agree  that  the  traditional  life  cycle  is  not 
evolutionary,  with  the  exception  of  Naumann  and  Jenkins 
[Bef.  62],  (see  also  figure  4.1)  Basili  [Ref-  65],  Bally  and 
ethers  [Bef-  68],  Earl  [Bef.  64],  Mason  and  Carey  [Ref.  76], 
and  Zvegintzov  [Ref.  57]  all  attempt  tc  force  a  cyclic 
structure   on  software   development, 

Perhaps  a  review  of  evolution  is  in  order.  When 
some  thing  (animal,  crganizaiton,  or  design)  evolves,  it 
begins  simply  (a  few  cells,  a  few  people,  a  few  details  and 
many  simplifying  assumptions)  and  grows  in  complexity,  often 
changing      remarkably      from    ixs      humble      beginnings.  This 

process    is   clearly    net  cyclic.  Rather,      a    betner   image   is 

the  spiral,  much  like  the  spiral  coil  of  the  shell  of  the 
Nautilus,  growing  in  size  yet  maintaining  the  essential 
nature   it   began    with. 

Figure  4.2  illustrates  the  evolutionary  nature  of 
prototypes.  Each  "chamber"  can  be  considered  to  be  a  single 
prototype,  the  wall  of  the  "chamber"  denoting  the  point  of 
refinement  and  enhancement.  The  only  restrictions  on  the 
number  of  "chambers"  (prototypes)  are  in  the  environment 
(exhausted  resources,  end  of  time,  too  complex  or  unwieldy, 
and    so   en) . 


62 


Figur«  4.2        Evolution  of    Prototypes- 

G.       SOMMiEY    AND    INTEBMEDIATE    CONCLUSIOHS 

This  chapter  has  explored  the  multi-faceted  aspect  of 
the  software  prototype:  the  process,  its  role  as  a  model, 
construction  strategies,      and    uses.  The   chaptsr    concludes 

with      a      persuasive      argument        that      prototypes      explicitly 
support   the    seven  design   slements. 
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Several  conclusicns  can  be  stated  at  this  time.  First, 
the  current  practice  cf  software  engineering  only  recognizes 
a  few  cf  the  design  elements  described  in  Chapter  II. 
Software  design  completely  ignores  the  fact  thax:  these 
elements      are      interrelated   and      mutually      dependent.  The 

traditional  method  of  software  development  only  worsens  the 
problem. 

Second,  the  prototype  approach  to  software  design  and 
development  naturally  supports  the  set  of  design  elements. 
For  example,  the  prototype  approach  encourages,  requires, 
and  exploits  the  interaction  and  communication  between  the 
user  and  designer.  Ey  making  this  explicit,  prototypes  will 
lead    to    a    better   design. 

Third,  developing  better  systems,  delivering  them  on 
time  and  within  budgets  are  in  our  best  interests.  The 
prototype  approach  will  allow  software  engineers  and 
designers   to  achieve   these    goals. 

The  next  chapter  briefly  describes  software  engineering 
environments  and  how  such  an  environment  could  and  should 
support   software   prototyping. 
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V.    THE   SOFTJABE   EMGISEEHING    EHVIBONMENT 

A.       IMTBOEOCTION 

Most  authors  agree  that  prototyping  has  become  possible 
through  recent  develcpments  in  computer  technology  [Ref.  61, 
62].  Ccllectively,  this  technology  is  called  the  software 
engineering  environment  (SE2)  [aef.  83],  the  programming 
support  environment  [Eef.  107,  105],  or  the  software  devel- 
opment   environment    [ Bef .    84  ]. 

There  are  as  many  definitions  for,  as  there  are 
references   to,        a    software      engineering   environment.  The 

definition  offered  by  Hausen  and  Muellerburg  s^ems  to  be  the 
most    satisfying: 


[A  Software  Engineering  Environment  is  ]  an  instrumented 
and  organized  software  development  laboratory  where  many 
people  cooperate  viith  each  other  in  a  fully  organized 
worxina  orocess,  in  the  design^  construction,  examina- 
tion, tuning  and  maintenance  or  software.  [Ref.  83  :  p. 
147].  '■ 


Generally  speaking,  the  literature  cites  two  approaches 
to  computer-aided  design  for  software  development:  1)  the 
SE2  is  a  systematic  approach,  and  2)  toolboxes  or  toolkits 
which  support  specific  software  development  activities 
[Eef*  85].  The  UNIX  development  environment  is  an  excellent 
example  of  -^he  toolkit  approach  [Ref.  86].  The  facilities 
of  UNIX  may  be  thought  of  as  a  "tool  kit"  from  which  the 
developer  can  select  tools  that  are  appropriate  for  a 
specific  task.  Detailed  discussions  of  the  UNIX  environment 
and   available  tools    can   be    found   in   [Ref-    87    ,    88]. 

The  toolkit  approach,  however,  has  been  criticized 
because: 
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1.  Tools  are  not   organized      to  support    specific   software 
d€V6lcpment    methodologies; 

2.  Tools  do    not      capture   management    or   control      data   for 
software    development;    and, 

3.  Individual  tools  are  largely  uncoordinated  [Ref-  89]. 
Lauber  has  reviewed  11  tool  systems  in  practical  use  and 
finds  that  only  two  systems  (PSL/PSA  and  PDL)  are  m  wide 
use.  8 

There  are  several  "programming"  environments  in  active 
use  (for  example,  Interlisp  [Ref.  90  ,  86  ,  91]  ),  or 
planned  (for  example,  the  Ada  programming  support  environ- 
ment (APSE)  [Ref.  93]  ).  Unfortunately,  there  is  no  3E2 
which   specifically      supports   the      prototype   process.  This 

chapter  will  first  describe  some  general  characteristics  of 
SE2s  and  then  explain  those  elements  of  SS^s  which  are 
needed   to   support   software    design   and   prototyping. 

E.       CHARACTERISTICS    Cf   SOFTIARE    ENGINEERING    ENVIRONHENTS 

''  •      development    Support    Tasks 

There      is   general      agreement      that      an   SE^      supports 
three    development   "tasks":         1)      software    production   manage- 
ment,   2)      technical    aspects    of   software    development,      and   3) 
user    participation    in  applications  development  [Ref.    83,      94 
,      95].  An  SE2      aids   software      management   by      "capturing" 

information  about  design  decisions  and  the  progress  of  the 
development  itself.  An  SE2  supports  software  development  by 
providing      automated      tools.  During      rhe      developmen*:      of 

specific  applications,  the  SE2  places  special  emphasis  on 
the    rcle   of   user-designer  interaction. 


^Erofclem  Statement  Language/Problem  Statement  Analyzer 
and  Prcgiam  Design  language.  A  derailed  review  of  the 
various  tools  and  environments  in  current  use  can  be  found 
in  S^ffl^csium  on  Software  Engineering  Environments  ,  Huenke, 
edi'^Eor.  ~ 
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2.  Int*;  grated 

An  integrated  SE^  will  support  the  three  development 
tasks  by  unifying  the  tasks  into  an  ensemble.  Integration 
applies  to  the  ease  of  using  and  the  ease  of  documenting 
those  activities  associated  with  individual  tools  [Ref-  84]. 
Perhaps  cne  of  the  mere  important  characteristics  of  an  SE^, 
integration  makes  it  easier  to  combine  various  tools  in 
order  to  perform  a  specific  function. 

3.  Uniform 

A  variety  of  automated  tools  are  used  by  the  SS2  to  support 
the    thrse   development  tasks.  For   reliable   operation,      the 

tools  must  be  consistent  with  one  another  [Eef.  8U,  9U  ,  95 
,  96].  If  one  tool  is  consistent  wirh  the  rest,  the  SE^ 
will      be   easier      to    use.  It   is      easier   to     learn   and      use 

special  formats  and  command  structures  when  they  are  consis- 
tent   among   all    of   rhe  tools. 

^  •      Support    a   Solution    Strategy 

Ihe  technical  aspects  of  software  development 
require  the  SE2  to  support  two  solution  strategies,  cne 
gensral  and  the  ether  specific.  Generally,  Soni  and  others 
believe  that  the  SE^  must  support  different  ways  of  solving 
the  problem.  [Ref-  84].  That  is,  the  SE^  should  support 
many  different  ways  of  solving  problems.  It  should  be  flex- 
ible enough  any  problem-solving  strategy.  For  the  specific 
strategy,  Wasserman  and  others  believe  that  an  SE^  must 
support  both  the  software  life  cycle  model  (the  • waterfall* 
model)  and  any  particular  software  development  methodology 
which  does  not  diverge  very  much  from  that  model  [Bef.  94, 
95,  97].  In  either  case,  the  objective  is  the  same:  to 
arrive   at   a    solution. 
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5 .      Adactabl-s 

For  practical  reasons,  an  SE^  should  be  adaptable. 
In  most  organizations,  each  of  the  development  tasks  is 
covered  by  different  organizational  groups,  each  wixh  their 
own  styles,  attitudes,  and  so  on.  Also,  the  individuals 
within  each  group  bring  different  perspectives  to  the  job. 
With  such  a  wide  range  of  personalities,  a  collection  of 
tools  should  bs  flexible,  changeable,  even  extensible 
[Ref.  8U].  The  SE2  should  be  able  to  adapt  to  the  design- 
er's (or  user's)  sophistication  and  should  provide  defaults. 
Defaults  cculd  be  easily  changed  as  users  become  more 
sophisticated  [Ref .    SU,   95,    96]. 

6 •      Functionally   Dnigue 

Within  each  development  task,  there  are  a  number  of 
unique  functions.  To  reduce  ambiguity,  misunderstanding, 
and  errors,  tools  within  an  SE2  must  be  functionally  unique. 
That  is,  they  must  have  a  singular  purpose  [Ref-  84,  94,  95, 
96].      Each    tool    must    te   limited   to  a    single   design   function. 

"7  •      I  Interactive 

An  SE2  must  have  interactive  system  capabilities. 
[Ref.  85,  84,  94,  95,  98].  There  are  two  reasons  for  this: 
interactive  systems  aid  communication  among  the  participants 
in  design,  and  designers  can  work  at  their  own  pace  (inter- 
actively) rather  than  someone  else's  (batch) .  User  partici- 
pation, cne  of  the  development  tasks,  is  simplified  when 
using   interactive   systems. 

8  •      Recent    D eve  1  c^meiits 

Two  ideas  about  SE2s,  personal  development  systems 
and  a  software  engineering  knowledge  base,  seem  to  unify  the 
three    development  tasks  and      embody   the   characteristics    just 
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statfrd.  Personal  development  systems  have  all  of  the  char- 
acteristics discussed  (integrated,  uniform,  support  a  solu- 
tion strategy,  adaptable,  functionally  unique,  and 
interactive) .  Their  most  important  feature,  though,  is  the 
dedicated  support  to  a  single  designer  [Ref-  89  ,  9U  ,  95]. 
A  software  environment  knowledge  base  would  capture  informa- 
tion about  the  design  activity  (for  example,  design  deci- 
sions) as  well  as  the  development  process  (a  continuous 
effort)  for  managers,  designers,  and  users  [Ref.  96].  This 
knowledge  base  would  make  the  information  easily  available 
and    wculd   be  done   autcmatically. 

C.       A    SOFTiARE    ENGINEERING    ENVIRONMENT    FOE    PROTOTYPES 

Mcst  authors  agree  that  a  'successful*  SE^  must  support 
a  certain  view  of  the  design  process  [Ref.  85,  94,  95,  97]. 
Following  the  lead  of  Lauber  [Ref.  85],  a  collection  of 
tools,  or  components,  which  support  the  set  of  seven  design 
elements  of  Chapters  II  and  III,  and  which  suppcrt  the 
develop  me  r.t  of  prototypes,  covered  in  Chapter  IV,  is 
presented.  This  is  followed  by  descriptions  of  how  such 
components  suppcrt  software  design  principles  and  proto- 
typing. 

1 .      Technical  Co tt£onent s 

There     are        several      components      which        should     be 
included    in    an    SE2    [Ref.    62,    75,    79,    83,    101]. 

a.      Database   Management   Systems    (DBMS) 

A  DBMS  serves  two  purposes  in  an  SE2.  First, 
the  DBMS  enables  storing  and  retrieving  information  about 
the  design  as  well  as  the  development  process.  For  example, 
a  record  could  be  kept  of  when  each  version  of  the  prototype 
was    released,      who    designed      it,      relevant    design   decisions. 
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and   so   on.  Second,      a   DBMS    allows    for      •quick'    design   and 

programaing  of  data  handling  features  [Ref-  62,  61,  83]. 
Becall  that  the  ability  for  quick  turnaround  of  a  working 
system  to  the  user  is  a  necessary  feature  in  many  proto- 
typing  situations. 

b.  Generalized  Input   and   Output   Software 

Query  languages,  report  generators,  and  report 
writers  are  often  features  of  a  DBMS  (for  example,  FCCOS, 
RAMIS  II,  and  NOMAD  provide  these  features) ,  These  features 
allow      for    easy      data  retrieval      and      data    update.  Report 

generators  can  produce  complicated  reports  with  minimal 
programming   effort    [  Hef .    61,   62,    79,    101]- 

c.  Graphics   Tools 

Graphics  are  ideal  for  representing  the  large, 
and  often  complex,  s-ructures  of  non-trivial  software 
designs.  These  tools  are  particularly  suited  for  the  ireth- 
odolcgies  which  use  structure  charts.  For  exampl-^,  Delisle 
[Ref.  102]  describes  a  set  of  graphics- based  tools,  an  Edit 
tool,  an  Evaluate  tocl,  a  Format  tool,  and  a  Clean-up  tool, 
which   were    developed   to   support   Structured    Analysis) . 

d.  High-level   Languages 

High-level  languages  (variously  described  as 
non-procedural  languages,  formal  specification  languages, 
and  so  on)  have  one  objective,  flexibility  [Ref-  62,  83, 
101 ]-  Such  languages  enable  the  designer  to  describe"  what 
to  do"  rather  than  "hew  to  do"  it.  The  system  resolves  the 
procedure  and  should  produce  executable  machine  code.  The 
designer,  given  such  a  tool,  can  use  abstraction  to  its 
fullest  extent  (the  Gamma  software  engineering  system 
(Ref-    103],    for    example,    specifically    supports  abstraction). 
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€.      Interactive   Systems 

I^vices  and  equipment  (for  example,  w-orking 
stations)  which  support  interaction  are  essential  [Hef.  61, 
62,  83,  98].  Interactive  terminals  give  users  and  designers 
the  perception  of  rapid  and  efficient  operarion  and  revi- 
sion. Generally,  these  facilities  are  adapted  from  the  host 
computer  or  network  of  the  SE2.  (Personal  development 
systems  cculd  be  thought  of  as  extensions  of  interactive 
systems. ) 

f,  Applicaticn-ori ented   Models 

Models  are  an  important  feature  of  an  SE^.  They 
are  used  to  support  human  decision  making  [Ref.  61,  62]. 
Examples  of  models  which  are  potentially  useful  are  finan- 
cial lodels  (as  in  FOCUS)  or  simulation  models.  Real-world 
modelling  [Bef.    U3 ]    is  also   an    important   element    in    the   SE^, 

g.  Tools  fci  Software   Testing 

There  is  clearly  a  need  for  tools  which  siiclify 
software  testing  [Ref.  83,  101]-  Hausen  and  Mu«=llerburg 
report  that  most  tools  of  this  type  concentrate  on  verifica- 
tion and  validation,  that  is  convincing  ourselves  that  the 
program    will     execute   properly.  They    argue      that   software 

tools  fcr  prcgram  testing  should  cover  more  than  just  veri- 
fication and  validation.  They  recommend  a  philosophy  of 
quality  improvement  which  includes  quality  assurance 
(defining  software  standards  and  controlling  their  cbserva- 
tion)  ,  acceptance  testing  (demonstrating  to  the  user  that 
the  software  is  acceptable  for  operation) ,  and  verification 
and    validation. 
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2 .      Su^£ort    for    Scftware   Design 

Any  SE2  aiust  te  based  on  a  particular  view  of-  soft- 
ware design.  [Ref.  65,  94,  95,  97].  The  view  presented  in 
Chapters  II  and  III  is  unique,  although  elements  of  that 
view  may  be  supported  in  different  ways  by  different 
systems. 

Ihe  SE2  must  recognize,  and  provide  facilities  for, 
the   symmetrical      and   adaptable   process      of   design.  If   the 

solution  to  a  problem  changes  the  problem,  features  of  the 
SE2  must  allow  revision,  interactive  use  by  clients  (it  is 
their  problem,  after  all),  and  record-keeping,  especially  of 
decisions. 9 

The  satisficing  aspect  of  design  may  best  be  met  by 
using  the  modelling  tools  of  the  SE^ ,  Simulatior.  tools  can 
help  answer  "what  if"  and  performance  questions.  Financial 
models      can     help      decide      economic      questions.  Planning, 

contrcl,  and  estimating  models  can  also  help  to  decide  on 
the    wcrth   of  various    tradeoffs. 

The  "wicked  problem"  aspecr  is  particularly  vexing 
in   the    SE^.  High-level  languages   can    help      by    allowing   an 

abstract  description  as  a  formulation  of  the  problem.  The 
abstract  statements  are  then  transformed  by  the  system  into 
concrete    (that    is,    executable)    code  [  Ref .    105,    106,    107]. 

Communications  between  the  user  and  the  designer  is 
aided  by  interactive  systems.  Graphics  also  aid  user  (and 
designer)  comprehension.  Alexander  and  others  have  shown 
how  the  notion  of  patterns  helps  bridge  the  communication 
gap.  Kuc,  and  others,  IRef.  80,  84,  108,  109,  110,  111] 
have  adopted  this  concept  in  their  "forms- based"  software 
development    environment.         The    'forms'    within   the   system   are 


'White  [Ref.  1041  oresents  a  model  for  recording  rele- 
vant information  acout  design  decisions  durina  software 
develop  me Et . 
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used  tc  identify  and  define  'patterns*  that  are  afcovs  the 
level  of  prcgramming  language  constructs.  Although  a  full 
discussion  cf  the  TRIAD  (TRee-based  Information  Analyzer  and 
Developer)  system  is  teyond  the  scope  of  this  work,  it  is  an 
excellent  candidate  for  an  SE^  which  supports  software 
prototyping. 

The  interactive  facilities  and  modelling  features  of 
the  SE2  will  help  tc  aid  the  learning  process  in  design. 
The  notion  of  'learning  by  doing*  was  introduced  in  Chapter 
III.  Tc  support  that  notion,  the  SE2  should  allow  the 
designer  to  learn,  early,  the  consequences  of  a  design  deci- 
sion. The  designer  trust  then  be  given  the  chance  to  revise 
his    decision,   based    en  the    'operation*    experience. 

Organizational  issues  must  be  explicitly  recogrized 
in  ary  SZ2,  First,  there  are  organizational  resources  which 
are   needed      to    support      the    SE^:  programmers,      operators, 

managers,  space  and  facilities,  and  the  computer  hardware 
assocated  with  the  SE2,  Second,  the  work  patterns  and  work 
skills  cf  the  people  who  work  in  the  SE2  are  likely  to 
change.  Unfortunately,  most  current  development  environ- 
ments stress  the  environment  over  the  users  of  the  environ- 
ment [Ref.  98].  Typically,  those  environments  have  "quirks" 
which  require  people  to  adjust.  The  system  should  adjust  to 
the  skills  and  the  preferences  of  the  designers  who  use  it 
(using,  for  example,  custom  default  features).  If  we 
consider  the  SE2  as  an  element  of  a  complex  organization 
[Hef.  59,  60,  98],  the  environment's  interaction  with  people 
is  crucial;  without  that  interaction,  the  SE2  is  useless  in 
any    practical  sense. 

Finally,  the  SE2  must  explicitly  recognize  the 
evolutionary  aspect  of  software  design.  The  current  systems 
support  the  waterfall  model  of  software  development 
[Ref.  SU,  95].  The  database  management  system,  interactive 
facilities,    and    high-level    languages    will   easily    support    the 
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evolutionary     concept     of  design.  Report      generators      and 

report  writers  should  aid  the  documenration  process  as  the 
design   evolves. 

3.      SupFort    for    the   Prototype   Process 

The  process  of  developing  a  software  prototype  was 
covered      in     Chapter   IV.  There     are      four   steps      in      that 

process;  1)  identifying  the  user's  basic  requirenents,  2) 
developing  a  working  prototype,  3)  implementing  and  using 
the    prototype,    and    4)    revising   and  enhancing  the   prototype. 

An  existing  database  of  the  SE^  is  ideal  for  identi- 
fiying  the  user's  initial  requirements.  Hcwever,  there  are 
problems    if     the  database  is  empty,  Kangasallo   [Ref,    112] 

presents  a  model  in  which  information  requirements  are 
interpreted  as  a  set  of  complex  queries  by  the  database 
management      system.  Additional      features      of      that      ircdel 

include  a  'program  constructor'  which  generates  code  based 
on  the  queries.  A  working  prototype  is  a  result  of  this 
model  • 

Another  method  depends  not  only  on  the  database 
management  system  but  also  en  the  automated  tools  within  the 
SE2.  Cheatham  [Ref-  105]  presents  a  system  in  which  the 
designer  and  user  develop  an  abstract  model  of  the  prcblsm 
(possibly  from  the  database).  Transformation  refinement  is 
applied  (by  the  automated  tools)  which  results  in  executable 
code--a    working    prototype. 

In  both  of  these  instances,  the  SE2  supports  the 
development  of  the  user's  basic  requirments  followed  fcy  an 
automated  process  of  developing  a  working  prototype.  It  is 
important  that  some  effort  be  made  to  analyze  the  user's 
requirements  so  that  reasonable  queries  can  be  made  and 
reasonable    codels    (of  the  problem)    can   be   developed. 
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other  systems  are  available  which  help  to  develop  a 
basic  set  of  user  requirements.  Some  ara  quixe  complsx 
[Ref.    32]   acd   might    be  difficult   to   integrate   with   the    SE^. 

Developing  a  working  prototype,  quiclcly,  should  not 
be      difficult        to      accomplish      in     the        SE^ .  High-level 

languages;        code      generators;  transformation      refinement 

(mentioned  above);  application  development  systems,  such  as 
ACT/1  [Be£.  76]  and,  application  generators  [Ref.  75]  make 
it  easier  to  develcp  working  prototypes.  Ideally,  the 
system    would  be    completely    automated. 

An  abstract  model  allows  the  designer  to  focus  mcr? 
easily  on  the  results  of  his  or  her  decisions,  rather  than 
the  implementation  details.  An  abstract  model  also  promotes 
flexibility    when   it    is  reused.      [Ref.    105] 

Inplementing  and  using  the  prototype  becomes  much 
easier  wlren  interactive  systems  are  used.  User  interaction 
is  essential  and  interactive  terminals  allow  the  user  to 
perceive  rapid  operation  and  revision.  They  also  help  to 
speed   user   evaluation  [Ref.    62]. 

Bevision  and  enhancement  are  facilitated  in  th?  SE^ 
by  using  the  database  management  system,  high-level 
languages  (and  abstract  models) ,  the  generalized  input  and 
output  tools,  and  graphics  tools.  The  database  contains  a 
record  of  past  designs  and  design  decisions,  changes  are 
easily  made  to  abstract  models  and  high-level  language 
constructs,  default  values  of  the  generalized  input  and 
output  tools  are  easily  adjusted,  and  the  graphics  tocls 
will  enable  both  users  and  designers  to  spot  patterns 
quickly.  The  user  is  quickly  accommodated,  the  database 
management  system  automatically  tracks  versions  and  design 
decisions,  and  the  designer  is  able  to  defer  low-pricrity 
details    without    fear     of   compromising   the   design:  the   SE2 

relieves  the  designer  of  much,  if  not  all,  of  the  drudgery 
normally   associated    with   software   design. 
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D.   SOHHAEY 

The  preceding  sections  have  reviewed  the  characteristics 
needed  in  a  software  engineering  environment,  have  identi- 
fied the  components  of  a  software  engineering  environment, 
and  have  described  hew  the  components  interrelate  to  support 
both  software  design  and  t.he  prototype  process. 

It  is  dcubtful  that  there  are  any  software  engineering 
environments  which  support  completely  the  idea  of  proto- 
typing- Tc  a  limited  degree,  commercial  systems,  such  as 
FOCUS,  NCMAD,  fiCT/1,  to  name  a  few,  support  particular 
aspects  cf  the  prototype  process.  For  example,  FOCUS  and 
NOMAD  facilitate  applications  programming  in  the  business 
community  by  allowing  the  designer  to  customize  reports  or 
other  appplications  for  a  specific  user,  or  group,  based  on 
an  already  existing  databa se--th6  vice-president  of  sales 
might  be  interested  in  the  sales  of  a  parxicular  product  in 
a  particular  geographical  area.  ACT/1,  and  other  similar 
products,  make  it  easiar  for  designers  to  customize  the 
formats  cf  terminal  screens  for  the  user. 

The  products  mentioned  here  are  three  of  several  hundred 
commercial  and  research  systems  and  environments.  This 
chapter  has  purposely  avoided  a  lengthy  review  of  any  of 
those  hundreds,  and  mentions  a  few  by  way  of  example  only. 
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¥1.    CASE    EXAflPLES 

The  four  cases  which  follow  were  chosen  because  in  each 
there  was  an  explicit  decision  began  to  develop  and  use 
software    prototypes    before    the   project   began. 

A.       SYMME1BI,    EFOLOTICN^    SATISFICIHG,    AMD    COHHUHICATION 

Heckel  [Bef.  113]  describes  the  process  of  developing  a 
ptototype  while  designing  the  Craig  translator.  The  project 
team  explicitly  chose  to  develop  prototypes  for  several 
reasons.  First,  they  were  concerned  about  the  problems 
which  users  would  actually  experience,  rather  than  these 
problems  which  the  designers  imagined  might  be  important. 
This  concern  is  directly  related  to  the  symmetry  aspect  in 
design.  That  is,  the  solution  and  problem  interrelate  such 
that  the  solution  depends  critically  upon  the  context  of  the 
problem.  In  this  case,  the  context  is  the  consumer's  use  of 
the      Translator.  If     the      product      does      not      perform     as 

"expected",    it    will    net    sell. 

Second,  the  project  team  was  interested  in  postponing 
decisions  about  restraints  on  the  final  system  until  they 
had      to.         In      other   words,  their      design   evolved.  The 

designers  ignored  certain  restrictions  which  had  been  placed 
on  memory  size,  as  long  as  they  carefully  considered  the 
effects  of  their  decisions  on  the  production  version  of  the 
Translator. 

Third,  the  project  team  planned  to  use  the  prototype  as 
the  software  specification.  Because  they  had  two  "versions" 
of  the  prototype,  a  black  box  translator  and  the  program 
listing,  they  thought  that  they  would  avoid  the  traditional 
misunderstandings   and  contradictions    often      found    in   written 
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software  specif icaticns.  In  this  case,  the  designers  were 
concerned  atout  communications,  not  only  between  the  "user" 
and   the    "designer"    but  also    among  themselves. 

Heckel's  description  shows  that  the  prototypes  (there 
were  30  versions!)  were  used  to  clarify  requirements  and  to 
verify  the  feasibility  of  the  design.  Heckel  states  that  if 
they  had  been  forced  to  make  a  particular  design  decision 
earlier  than  they  did,  they  probably  would  have  made  a  less 
satisfactory  decision. 

The  project  was  judged  a  success,  although  progress 
seemed  slew  and  painft:!.  Heckel  identifies  four  benefits  of 
developing    prototypes: 

1.  The    project    team   could   keep  trying   new  things; 

2.  The  prototype  was  a  good  model  of  the  final  product, 
sc  everyone  had  similar  expectations  about  what  the 
product    would    do; 

3.  Several  decisions  could  be  postponed  without 
affecting  the   schedule;    and, 

U.      The    designers    focused   their     efforts   on   opportunities 
rather  than    problems. 
The    development    process    had   some    disappointments:      soft- 
ware   development      took  longer      than    expected     and    the      final 
product   took     more    menory      than   expected.  Heckel   did      not 

speculate  on  whether  these  "disappointments"  could  have  been 
avoided.  One    interpretation      is  that      the   designers      were 

unable  tc  meet  all  of  their  objectives  and  when  time  ran  out 
their  design  was  judged  to  be  good  enough.  Thus,  the 
"disappoir.tments"  can  be  attributed  to  the  satisficing 
aspect  of  design,  especially  the  need  for  more  memory.  The 
designers  obviously  made  a  trade-off  between  the  "goodness" 
of  the  product  and  the  amount  of  memory  they  had  originally 
planned. 
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Ihi^  case  illustrated  how  the  use  of  prototypes 
addresses  the  symmetry,  evolution,  communications,-  and 
satis f icing   aspects   of  design. 

B.       LEIBNING 

Hemenway  and   McCusker  [ Bef .    116]    describe  an    exploratory 

project      which    is      leading    to      the  development      of   an      order 

negotiation   and      entry  support   sys-em    for      telephone   service 

(the    Bell   system).  The   project   is    the      development    of   the 

user    interface    and   the  supporting  software   for  the   system. 

There  are  two  reasons  given  for  building  an  operational 
prototype:  1)  to  evaluate  the  user  interface  and  2)  to 
assess  the  feasibility  of  a  particular  software  architec- 
ture. Even  though  the  reasons  coincide  with  two  uses  of 
prototypes  (that  is,  to  clarify  user  requirements  and  to 
verify  the  feasibility  of  a  design)  they  are  related  tc  two 
aspects  cf  design.  The  aspects  are  learning  and  communica- 
tion   fcetween  the   designer   and    'iser. 

Prototypes  of  the  software  were  daveloped  to  determine 
whether  a  table-driven  system  could  be  designed.  Prototypes 
cf  the  user-interface  were  used  to  determine  whether  the 
user-interface  would  substantially  increase  the  length  of 
time  service  representatives  spend  on  orders  (compared  to 
manual   order  entry   and  search). 

The  case  concludes  by  stating  that  the  results  of  the 
prototype  evaluation  led  to  making  several  recommendations 
to  the  designers  of  the  first  release  of  the  system.  Hence, 
the  prototype  served  to  hel£  the  designers  learn  more  about 
their    scluticn   and    their   problem. 
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C.       ilCKED    PROBLEMS,    COMMUNICATIONS,       AND    THE    OBGANIZATIONAL 
CONTEXT 

Jenkins  [Ref.  114]  discusses  how  the  decision  tc  develop 
a  prototype  led  to  successful  development  of  an  automated 
data  processing  facility  for  the  Congressional  Budget 
Office. 

Two  aspects  of  software  design  are  apparent  in  this 
case:  1)  communications  between  users  and  designers  and  2) 
the  organizational  context  of  the  system.  Communications 
between  the  designers  and  users  was  greatly  improved  by 
using  a  prototype.  Bather  than  try  to  decide  on  the  design- 
er's effectiveness  ty  reviewing  written  specifications, 
managers  witnessed  operating  demonstrations.  The  prototype 
also  showed  non-technical  users  what  it  was  possible  to  do 
in    their   application   areas    with   the   new   tools. 

By  far  the  most  important  aspect  illustrated  by  this 
case,  is  the  concern  of  the  designers  for  organizational 
issues.  The  Congressional  Budget  Office  serves  the  needs  of 
the  Congress,  admittedly  a  ccmplax  organization.  So,  the 
designers  needed  immediate  responses  to  Congressional 
inquiries,  because  when  information  is  needed,  it  is  often 
needed    iiiiediately    or  its  value   is  lost. 

This  organizational  aspect  is  also  closely  related  to 
wicked  problems.  Secall  that  wicked  problems  refer  to 
social  system  problems  which  are  ill-formulated,  where  the 
infornaticn  is  confusing,  where  there  are  many  clients  and 
decision-makers      with     conflicting  values,        and      where      the 
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ramifications  in  the  whole  system  ara  thoroughly  ccnfusing. 
Clearly  Congress  is  faced  with  these  kinds  of  problems. 
There  is  every  reason  -o  expecr  that  the  Congrss'sional 
Budget  Office  deals  with  similar  problems  when  responding  to 
Congressicnal  inquiries,  lo 

Ih^  casg  presented  b^  Jenkins  illustrates  how  prototypes 
can  aid  software  design  when  faced  with  critical  organiza- 
tional  issues  and   wicked    problems . 

D.       COBHUNICATION,    LEARNING,    AND    EVOLUTION 

Groner  and  others  [  Ref .  115]  present  a  case  of  using 
prototypes  to  clarify  the  user's  requirements.  The  case  is 
unusual  because  it  started  with  a  proposal  from  outside  the 
user's  ccmmunity.  The  designers  set  out  to  determine  if  and 
how  computer  tachnclogy  could  meet  the  information 
processing    needs  of    medical    researchers. 

This  case  is  a  clear  illustration  of  the  importance  of 
communications  between  the  designer  and  the  user  and  the 
representation    used    for   communicating. 

Prototypes  were  required  in  the  requirements  analysis 
phase  because  without  concrete,  working  examples  our 
potential  'osers  could  not  be  sura  that  computer  systems 
are  needed,  what  functions  they  should  perform,  or  how 
they   wculd  use  them.      [Ref.    115   :    p.    100*] 

Less  clearly  stated  is  the  implication  of  learning 
during  the  design  process.  The  intitial  design  of  the 
prototype      was      based     on      the      designer's      knowledge      about 


loconsider  the  fluctuations  from  Congress  to  Congress, 
chairman  to  chairman,  committee  to  committee;  from  year  to 
year,  week  to  week,  and  even  from  hour  to  nour  during  the 
Budget   Committee   markup  sessions   [Ref.    114    :    p.    22]- 
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infornaticn  processing  needs  for  medical  rssearch. 
Subsequent  versions  were  improved  based  on  use  by  and 
comments  from  clinical  researchers.  The  project  partici- 
pants 


.  .  .  agreed  to  learn  about  each  other^s  disciplines, 
then  define  prcblems  and  attempt  -co  devise  and  evaluate 
solutions  in  collaboration  with  others  in  the  -araet 
user  community.   [ Bef •  115  :  p.  101] 


The  project  used  an  incremental  implementation  strategy 
(evcluticn)  under  which  major  software  releases  ware  sched- 
uled approximately  every  four  months.  Several  hundred  soft- 
ware changes  were  made  over  a  period  of  a  year  and  half. 
This  case  shows  how  prototypes  can  be  used  to  create  the 
final  system. I ' 

Ih^  £§^f  presented  by  G  roner  and  others  is  an  excellenr 
S^J£2^  2J  hsa  c cm m u n ica ti o n s ,  learning*  and  evolution  are 
intertwined  in  software  design.  The  development  cf  proto- 
types helped  all  of  the  design  participants  cope  with  those 
aspects  CI  s of t. y ar e  design. 

E.   SOMMABY 

These  cases  illustrate  how  prototypes  help  designers 
cope  with  the  seven  aspects  of  design  which  were  covered  in 
Chapters  II  and  III.  In  each  of  the  cases,  the  authors 
point  to  success.  For  Heckel,  the  prototypes  led  to  a 
product  that  was  easy  to  use,  had  a  number  of  useful 
features,  and  was  implemented  on  a  single-chip  micropro- 
cessor. 


i^The  case  description  leads  the  readar  to  think  that  a 
"production"  system  was  not  developed.  Every  indication  is 
that    the    prototypes    evolved    into   tne    production   system. 
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Hsmenway  and  McCusker  say  only  that  prototype  evaluation 
led  to  reccinmendations  to  the  designers.  From  this,  w^  can 
safely  infer  that  the  prototype  aided  the  designer* s 'ander- 
sranding   of   the    froblem. 

Fcr  Jenkins,  the  overall  assessment  to  the  prototype  was 
positive.  Managers  liked  the  idea  of  a  prototype  because 
there  was  nc  prior  commitment  to  a  particular  course  of 
action. 

Groner  and  others  believe  that  the  greatest  benefi-  of 
the  prototype  is  that  the  prototypes  are  concrete,  working 
examples  cf  computer  systems  which  are  meeting  everyday 
needs . 
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?II.     CONCLUSIONS 

A  new  view  of  design  was  presented  in  Chapter  II.  This 
view  identifies  a  set  of  seven  interrelated  and  mutually 
dependent  elements  which  were  found  in  the  literature. 
Support  for  these  elements  was  found  throughout  the  computer 
and  information  science  literature.  The  set  of  seven 
elements  explains  how  best  to  cope  with  the  problems,  ambi- 
guity,   and   uncertainty  associated   with  software   design. 

The  process  of  developing  a  software  prototype  is 
presented  as  the  most  appropriate  way  to  incorporate  the 
design  elements  into  software  design.  In  fact,  the  proto- 
type process  exploits  certain  elements,  such  as  communica- 
tion between  the  user  and  designer,  to  improve  the  overall 
design   of   the  software. 

One  of  the  more  important  conclusions  is  that  software 
designers,  especially  designers  of  large-scale  systems,  have 
much  to  learn  from  designers  in  other  fields.  The  software 
design  literature  shews  little  evidenca  of  influence  from 
other      design   fields.  This    wcrk      is   a      start   -oward      that 

needed   transfer    cf    knowledge. 

The  software  prototype  may  be  the  sensible  way  tc  design 
large-scale   systems.  Recall   that   complex      design    problems 

have      been   called      wicked      problems.  If   some      large-scale 

system  developments  are  'more  wicked*  than  others,  then 
developing  prototypes  seems  to  be  the  only  way  to  design  the 
system. 

Software  prototyping  enables  users  and  designers  to  cope 
with  ill-defined  problems  and  changing  requirements.  Past 
experience  indicates  that  bad  technical  engineering  is  not  a 
problem  with  software  development.  Rather,  unsatisfactory 
design      decisions     and      faulty        information      are      the      real 
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problems.  Software  prototypes  provide  a  mechanism  which 
allows  designers  to  test  their  decisions  and  t,o  learn  mere 
about      the    problem.  The      prototypes      also    allow      users      a 

consTrucyive  environmen-c  in  which  to  express  their  satisfac- 
tion cr  dissatisfaction  and  a  stimulant  in  learning  hew  to 
deal    wi-h  their    problems. 

Software  prototypes,  however,  present  special  difficul- 
ties fcecaus€  -hay  ar€  not  the  universal  remedy  for  software 
design  problems.  Careful  management  is  needed  to  ensure  the 
software  ptototype  is  really  designed  and  not  just  put 
together.  Careful  thought  and  planning  are  necessary  before 
coding  begins.  Managers,  designers,  and  users  must  remember 
that  a  software  prototype  is  an  experiment.  Judgement  and 
commitment  are  needed  to  control  er.diiss  iteraticns. 
Managers  nust  have  the  wisdom  to  know  when  to  step.  Often, 
while  developing  successive  prototypes,  there  is  a  tendency 
to      delay      formally      documenting   the      system.  While      this 

problem  is  not  unique  to  prototypes,  there  must  be  attentive 
managenient  snd  commitment  to  ensure  adTCuat-;  and  ccuplete 
documentation. 

In  spite  of  these  cautions,  evidence  indicates  that 
developing  and  using  software  prototypes  is  the  best  option 
for  coping  with  software  design  problems,  for  ensuring  the 
system  is  delivered,  and  for  ensuring  a  satisfied  user 
population. 
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VIII-  RECOBMENDATIONS  FOR  FURTHER  STUDY 

A.  HABAGEIIEIIT 

D€V€lcping  software  prototypes  presents  management  with 
some  unusual  problems.  Many  of  our  current  management  tech- 
niques depend  on  getting  the  project  done  right  the  first 
time  [Ref.  117].  As  we  are  well  aware,  this  seldom  occurs. 
Research  is  needed  to  assess  the  effect  of  prototype  devel- 
opment  en    management. 

1.  Hew  does  the  manager  decide  when  to  cease  development 
of   prototypes?     When    is   the   project   ended? 

2.  Hew  do  managers  deal  with  increased  communications 
between  users  and  designers?  If  special  maragement 
ccntrols    are    needed,    how   far   should   they    go? 

3.  What  management  style  best  suits  managers  of  software 
pictetype   projects? 

4.  How  is  the  project  budgered  and  controlled?  Hew  is 
pr egress    measured? 

B.  ACQUISITION  AND  CONTRACT  MANAGEMENT 

Current  acquisition  and  contract  management  procedures 
and  regulations  for  software  appear  to  be  less  rhan  satis- 
factory, within  the  Federal  Government  generally,  anc  the 
Department  of  Defense  particularly.  Even  as  these  proce- 
dures and  regulations  are  changing,  there  is  some  evidence 
thai:  the  traditional  model  of  software  development  may 
become    required.  Ihe   Department  of      Defense   has      begun   to 

address  the  concept  of  software  prototypes  in  the  DoD 
Software  Technology  Initiatives  [Ref.  D0D8I  :  p.  69-71],  but 
this  research  appears  to  be  concerned  only  with  requirements 
specifications. 


86 


1.  Hew  can  or  how  should  acquititicn  and  contract 
management  procedures  and  regulations  accomoda-*  tha 
principles  of    design    and   software   prototyp<3s? 

2.  What  is  the  best  strategy  for  encouraging  acceptance 
of  the  software  design  principles  and  software  proto- 
types? 

3.  How  might  the  elements  of  software  design  and  devel- 
oping software  prototypes  help  with  the  acquisition 
and  contract  management  for  embedded  computer 
resources? 

C.  OBGANIZATIONAL    CCSTEXT 

Kling  and  Scacchi  [Ref.  59,  60]  reviewed  a  large  number 
cf  organizational  studies  while  developing  their  views  about 
the  effect  of  computer  systems  upon  organizations.  When 
their  ideas  are  considered  within  the  context  of  software 
prototypes,    further    research   is   needed. 

1.  How  will  chances  in  theories  of  organizational  devel- 
opment affect    the   process   of   developing   prototypes? 

2.  Is  any  one  organizational  theory  best  suited  for 
scftware    design  and    software    prototypes? 

3.  What    are    the    social    dynamics   of   software   design? 

4.  What  are  the  social  dynamics  of  developing  software 
prototypes? 

D.  QUALITY 

a  fundamental  part  of  design  is  to  satisfy  the  n^^eds  for 
quality.  Roolce  [Ref.  Rook82]  has  concluded  that  design  is 
the  most  important  factor  in  determining  overall  quality. 
Even  though  one  of  the  objectives  of  developing  software 
prototypes  is  to  achieve  user  satisfaction  (a  major  element 
cf  quality) ,  research  is  needed  to  determine  how  prototypes 
can    affect   software    quality. 
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1.  If  w€  accept  tbat  prototypes  will  affsct  a  change  in 
software  technology,  how  will  that  change  influence 
our  perceptions  of  quality?  That  is,  will  software 
prototypes  lead  users  to   expect   more  than   can    be   me-? 

2.  How  might  the  concept  of  Quality  Circles  fit  the 
process    of  developing  software    prototypes? 

3.  To  what  extent  will  software  prototypes  influence 
software  quality?  Since  prototyping  requires 
concensus,  who  is  ultimately  responsible  for  product 
quality  and  liability?  Should  anyone  be  "ultimately" 
responsible? 

E.       REPRESENTATION 

The  software  prototype  is  the  ultimate  representation  of 
the  user's  requirements.  The  written  specification  anchors 
the    other   end  of  the   representations    scale. 

1.  What  other  types  of  representations  can  aid  software 
design  and  the   development   of    software   prototypes? 

2.  What  methods  ar?  suitable  for  representing  abstrac- 
tions when  identifying  a  user's  requirements  before 
developing  a    software   prototype? 

3.  Hew  do  different  representations  affect  our  percep- 
tions and  real  world  knowledge?  Can  different, 
initial  rapresenta-cions  lead  to  quicker  design  and 
development    of  software   prototypes? 
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